[Python-Dev] confusing exec error message in 3.0 (original) (raw)

Steve Holden steve at holdenweb.com
Thu Aug 28 09:34:27 CEST 2008

Guido van Rossum wrote:

On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano <steve at pearwood.info> wrote:

On Thu, 28 Aug 2008 08:39:01 am Georg Brandl wrote:

Fredrik Lundh schrieb:

(using 3.0a4)

>>> exec(open("file.py")) Traceback (most recent call last): File "", line 1, in TypeError: exec() arg 1 must be a string, file, or code object, not TextIOWrapper so what's "file" referring to here? (the above works under 2.5, of course) See http://bugs.python.org/issue1762972 -- it has been decided to drop that possibility. Hmmm... I have a concern with one of the patches in that issue; I refer to patch that changes the semantics of module's file attribute. Guido noted that exec(open(M.file).read(), M.dict) almost worked as a replacement for reload(), except that there were issues with file extensions (.py, .pyc, .pyo and even things like .pyc24). So it was decided that M.file should always point to the source file. But now that reload() is now moved into the imp module, I don't see that the justification for changing the semantics of M.file still exists. imp.reload(M) is much better for interactive use than exec(open(M.file).read(), M.dict). Is there still a justification for having M.file point to the source even if the module was actually loaded from the .pyc version? If so, what is that? Some years ago, as a newbie, I was having trouble with reload() repeatedly not picking up changes I was making to a module. The problem turned out to be user-error, but how I discovered that was by looking at M.file and noticing that Python was loading the .pyc file instead of the .py file I was expecting. Had M.file given misleading information, I would have been mislead for much longer. Here's a small contrived example under Python 2.5: import parrot parrot.file 'parrot.py' # pretend that I made changes to the source ... # in my editor, but forgot to save them ... reload(parrot) <module 'parrot' from 'parrot.pyc'> parrot.file 'parrot.pyc' I don't think M.file should lie and say it was loaded from a file that it wasn't loaded from. It's useful to be able to look at a module and see what file it was actually loaded from. While appreciate the use case, there are way more use cases where there's code that must painstakingly strip the trailing 'c' or 'o' from file in order to read the source code. Perhaps we should have a separate API for finding out whether a module was loaded from source or from a .pyc file; but I think it would be better to have such an API somewhere in the imp module. It's also possible to follow what goes on by watching the verbose -v output. Painstakingly? Surely the pain level isn't that high, and I agree with Michael that the file information would be better as the literal truth.

regards Steve

Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

More information about the Python-Dev mailing list