In "What’s New In Python 3.0" document, I can read "Removed
execfile(). Instead of execfile(fn) use exec(open(fn).read())". The
new syntax has two problems:

• if the file is not encoding in UTF-8, we get an unicode error. Eg.
  see issue bpo-4282
• exec() doesn't support newline different than \n, see issue bpo-4628

We need a short function which opens the Python file with the right
encoding. Get Python file encoding and open it with the right encoding
is a command pattern.

Attached patch proposes a function open_script() to open a Python
script with the correct encoding. Using it, execfile() can be replaced
by exec(open_script(fn).read()) which doesn't have to two binary file
problems.

-1. There is a much simpler solution to the problem: use exec(open(fn,
"rb").read())

martin> There is a much simpler solution to the problem:
martin> use exec(open(fn,"rb").read())

Ok... but there is the newline issue: (self quote) "exec() doesn't support
newline different than \n, see issue bpo-4628".

And open_python() can be used for other usages than execfile() ;-)

Note: tokenize.open_python() is maybe not the best module and/or function
name.

Ok... but there is the newline issue: (self quote) "exec() doesn't support
newline different than \n, see issue bpo-4628".

So that issue should get fixed, then.

And open_python() can be used for other usages than execfile() ;-)

Note: tokenize.open_python() is maybe not the best module and/or function
name.

I remain opposed to the entire concept.

> Ok... but there is the newline issue: (self quote)
> "exec() doesn't support newline different than \n,
> see issue bpo-4628".

So that issue should get fixed, then.

Ok, I will work in the other other issue. If bpo-4628 is fixed, this
issue becomes meaningless ;-)

It doesn't seem helpful to leave this issue open, particularly since the
title suggest there's a problem with execfile being removed and that's
not going to change.