This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author arigo
Recipients
Date 2005-04-10.13:10:52
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
In a number of situations, the .pyc files can become "corrupted" in a subtle way: the co_filename attribute of the code objects it contains become wrong.  This can occur if we move or rename directories, or if we access the same set of files from two different locations (e.g. over NFS).

This corruption doesn't prevent the .pyc files from working, but the interpreter looses the reference to the source file.  It causes trouble in tracebacks, in the inspect module, etc.

A simple fix would be to use the following logic when importing a .py file: if there is a corresponding .pyc file, in addition to checking the timestamp, check the co_filename attribute of the loaded object.  If it doesn't point to the original .py file, discard the code object and ignore the .pyc file.

Alternatively, we could force all co_filenames to point to the .py file when loading the .pyc file.

I'll write a patch for whichever alternative seems better.
History
Date User Action Args
2007-08-23 14:30:58adminlinkissue1180193 messages
2007-08-23 14:30:58admincreate