[ python-Bugs-1762972 ] 'exec' does not accept what 'open' returns

[SourceForge.net]

Bugs item #1762972, was opened at 2007-07-28 23:24
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brett Cannon (bcannon)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 'exec' does not accept what 'open' returns

Initial Comment:
Since the move over to io.py 'exec' no longer accepts what 'open' returns.  Looks like there is a type check in 'exec' for strings, files, or code object, but 'open' returns a TextIOWrapper that fails that typecheck.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-08-03 17:53

Message:
Logged In: YES 
user_id=6380
Originator: NO

Or we can change the semantics of __file__ to always point to the source
file.  I think that's acceptable behavior -- the current behavior seems
more of a pain than necessary.

I also think that adding imp.reload() makes sense; I was just saying
yesterday to a few fellow-Googler-Python-developers that I was already
missing reload().

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-08-03 17:42

Message:
Logged In: YES 
user_id=357491
Originator: YES

Hrm.  Well then we can either add something like __source_file__ to
modules, put 'reload' into the imp module (or on module objects as a
method), or have a function in imp (or as a method on modules) that returns
the source path (if it exists).

But having to do::

  M.__file__.rsplit('.', 1) + filter((lambda x : x[2] == imp.PY_SOURCE),
imp.get_suffixes())[0]

seems like a lot to memorize (let alone type in), especially since there
is even no error checking that the path is even to a source or bytecode
file to start with or that you end up with.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-08-03 17:14

Message:
Logged In: YES 
user_id=6380
Originator: NO

OK, let's ditch it (i.e. status quo) and also ditch execfile.

The one-liner you're looking for is *almost*

exec(open(M.__file__).read(), M.__dict__)

(where M stands for any already imported module), except for the nastiness
that if m.__file__ ends with .pyc or .pyo you'd have to strip the last
character.  (And to do this right you'd need help from the imp module
because those extensions may vary by platform -- e.g. I know of a company
that patches their Pythons to use .pyc24.)

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-08-03 17:09

Message:
Logged In: YES 
user_id=357491
Originator: YES

I am fine with ditching the feature and forcing people to deal with the
encoding issues externally to 'exec', although as you pointed out dealing
with any -*- encoding marker might be a pain without some library help
(although doesn't the parser pick up on this and handle those nasty
details?).

As for execfile, PEP 3100 has it listed for removal in favour of moving
people over to using 'exec'.

The main thing is trying to come up with an easy solution for replacing
'reload' with a reasonable one-liner when debugging at the interpreter.

And yes, I hope encoding declarations can go away and the world either
lives with just UTF-8 or BOM+UTF-16 (I really wish we could just require
this for all Python source files and start towards this, but I know some
people would flip out over that).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-08-03 16:26

Message:
Logged In: YES 
user_id=6380
Originator: NO

Arguably we don't need this feature any more.  The only reasonable way to
implement it would be to slurp the entire contents of the file into a
string and then exec that.  The caller might as well do this. 
Alternatively one could use execfile() (which takes a filename instead of a
stream).  The only advantage of using exec(<stream>) might be that it would
deal with encoding declarations transparantly; but we should probably have
a way to handle those somewhere in the library anyway, as it's also
necessary for other tools (e.g. modulefinder.py, pyclbr.py and
linecache.py).  Alternatively I'm not so sure that we will need to support
encoding declarations forever -- I'm hoping that at some point UTF-8 and
BOM+UTF-16 will take over the world.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1762972&group_id=5470