Bugs item #1051638, was opened at 2004-10-21 19:24 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1051638&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: Parser/Compiler Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Kevin Quick (kquick) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect traceback filename from pyc Initial Comment: The .pyc file apparently caches the entire path of the source file during compilation, causing it to report improper path information if the resulting code is moved and an exception occurs. $ python Python 2.3.3 (#1, Oct 18 2004, 16:10:24) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> ---------------------------------------------------------------------- >Comment By: Žiga Seilnacht (zseil) Date: 2007-04-03 09:16 Message: Logged In: YES user_id=1326842 Originator: NO This is a duplicate of bug #1180193: http://www.python.org/sf/1180193 ---------------------------------------------------------------------- Comment By: Kevin Quick (kquick) Date: 2004-10-30 08:01 Message: Logged In: YES user_id=6133 OK, I've done some more investigation and have some more details and clarification. I've attached another python script that demonstrates these additional clarifications: First, it runs sample scripts in a test directory. The sample scripts generate an exception, print that exception with traceback.print_exc, then raise to let the interpreter print the exception as it fails the script. The control script verifies that the output of traceback.print_exc matches the interpreter's traceback output. So far, so good. Step two demonstrates the first problem: the original directory is simply renamed; the previous location does not exist. The same sample scripts are run, and the output now shows that traceback.print_exc() output is *different* than the interpreter's traceback. Specifically, the interpreter prints the new, correct path, but the traceback.print_exc() prints the old path. Step three demonstrates another problem. The scripts are run from the new directory, but the old directory now exists, along files having the original .py names, but those files are now much shorter; the lines that will be referenced in the traceback do not exist. In the output from this step, note that the output from traceback.print_exc() and the interpreter traceback are again *different* from each other. In this case, both are fooled into reporting file paths in the old directory, but for a non-existent line the interpreter prints a blank line but traceback.print_exc() doesn't print a line at all. And finally, the .py files in the original directory are filled with nonsense (in python terms). This test case shows that the output from traceback. print_exc() and the interpreter *do match*, but both are fooled into showing file paths in the old directory and the nonsense from the new versions of the files. IMHO, I think that the output from the traceback.print_exc() and the interpreter traceback should be the same in *all* scenarios, and I also think that the path used for importing the module should be used in traceback reporting. Rather than encoding the full path of the .py source in the .pyc, the compiler should just encode the name portion, and use the path from the .pyc import and look for the .py in the same directory as the .pyc; if that's garbage, then so be it, but this will 99% of the time be more correct than the current behavior. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-24 02:40 Message: Logged In: YES user_id=80475 IMO, this is not a bug. A pyc file has no way of knowing the future locations of the source that originally created it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1051638&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
