Python – Wrong Filenames, Paths in Traceback

I copied some Python modules I wrote from my home computer over to a web host via FTP. I ran the code on the webhost and there was an error. The odd thing was that the traceback for the error mentioned file paths from where the modules were stored on my home computer. This really confused me for 10 minutes. I spent 10 minutes thinking there was some spooky connection between my home computer and my web hosting server.

Then I realized that I had also copied over .pyc files. So I tried deleting those from the web host directories and rerunning it. After that the traceback showed the correct file paths. My best guess is that .pyc files store the filepath where they were compiled to and the traceback reads that instead of looking at where the file is now located.

Does anyone have any more insight on this?

Update:
Perhaps I’m hitting one of these Python bugs:
[ 1180193 ] broken pyc files
[ 1051638 ] incorrect traceback filename from pyc

3 Responses to “Python – Wrong Filenames, Paths in Traceback”

  1. As stated in the second bug report, this is not really a bug. The .pyc files should have been recreated if the time stamps were properly moved, but the file transfer must have moved the .pyc files after the .py files. this sucks, but is the correct thing to do. The .pyc file caches .py file location that created it. This is done because moving a .pyc to a new directory does not mean that the .py file also moved. It would be MORE of an error to dynamical look somewhere else (and would arguably be a security risk).

  2. Good points, Doug. It does sound like the correct behavior. People just have to understand what’s going on. Hopefully this post will help with that a little bit.

  3. Just a quick follow up. We (work) use this behavior as part of out build system. Ad part of the build we pre-compile all the .py files into .pyc and .pyo files and move them into build directories. This way the build files are not part of the source directories. We then run from the .pyc’s and .pyo’s. This catches silly grammatical errors as part of the build, and maintains the proper error stacks. This is a little unorthodox, but it works quite well.