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 #4282
 - exec() doesn't support newline different than \n, see issue #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 #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 #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 #4628".

> So that issue should get fixed, then.

Ok, I will work in the other other issue. If #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.