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.

Title: incorrect traceback filename from pyc
Type: Stage:
Components: Interpreter Core Versions: Python 2.3
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: kquick, rhettinger, zseil
Priority: normal Keywords:

Created on 2004-10-21 17:24 by kquick, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit kquick, 2004-10-21 17:24 kquick, 2004-10-30 06:01
Messages (4)
msg22805 - (view) Author: Kevin Quick (kquick) Date: 2004-10-21 17:24
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.
msg22806 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-10-24 00:40
Logged In: YES 

IMO, this is not a bug.  A pyc file has no way of knowing
the future locations of the source that originally created it.
msg22807 - (view) Author: Kevin Quick (kquick) Date: 2004-10-30 06:01
Logged In: YES 

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 

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 

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 

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 
msg22808 - (view) Author: Ziga Seilnacht (zseil) * (Python committer) Date: 2007-04-03 07:16
This is a duplicate of bug #1180193:
Date User Action Args
2022-04-11 14:56:07adminsetgithub: 41057
2004-10-21 17:24:35kquickcreate