File paths printed in stack trace are where Python was built???
We distribute Python internally by building it in one place, and then distributing images of the entire install area to wherever it's needed. I just noticed something strange; when I got an error which caused a stack trace, the file paths in the printed stack trace refer to the directory where Python was built. Why is this? All other paths I can think of in Python are generated relative to where the binary is running, not where it was built. Is there a way to make the stacktraces point to where Python is running from, instead of where it was built? Traceback (most recent call last): File tProcess.py, line 27, in test_t1 server = subprocess.Popen(argv) File /emc/chacoj2/src/clean/smarts/thirdparty/python/2.5.1/ linux_rhAS40-x86-32/install/lib/python2.5/subprocess.py, line 593, in __init__ errread, errwrite) File /emc/chacoj2/src/clean/smarts/thirdparty/python/2.5.1/ linux_rhAS40-x86-32/install/lib/python2.5/subprocess.py, line 1079, in _execute_child raise child_exception AttributeError: 'list' object has no attribute 'rfind' -- http://mail.python.org/mailman/listinfo/python-list
Re: File paths printed in stack trace are where Python was built???
Actually, if you to get an error from a module built with zipimport it points to where that module was built as well. Kevin On Fri, Nov 28, 2008 at 9:22 PM, Roy Smith [EMAIL PROTECTED] wrote: We distribute Python internally by building it in one place, and then distributing images of the entire install area to wherever it's needed. I just noticed something strange; when I got an error which caused a stack trace, the file paths in the printed stack trace refer to the directory where Python was built. Why is this? All other paths I can think of in Python are generated relative to where the binary is running, not where it was built. Is there a way to make the stacktraces point to where Python is running from, instead of where it was built? Traceback (most recent call last): File tProcess.py, line 27, in test_t1 server = subprocess.Popen(argv) File /emc/chacoj2/src/clean/smarts/thirdparty/python/2.5.1/ linux_rhAS40-x86-32/install/lib/python2.5/subprocess.py, line 593, in __init__ errread, errwrite) File /emc/chacoj2/src/clean/smarts/thirdparty/python/2.5.1/ linux_rhAS40-x86-32/install/lib/python2.5/subprocess.py, line 1079, in _execute_child raise child_exception AttributeError: 'list' object has no attribute 'rfind' -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: File paths printed in stack trace are where Python was built???
On Fri, 28 Nov 2008 19:22:11 -0800, Roy Smith wrote: We distribute Python internally by building it in one place, and then distributing images of the entire install area to wherever it's needed. I just noticed something strange; when I got an error which caused a stack trace, the file paths in the printed stack trace refer to the directory where Python was built. My guess is that your build process generates the .pyc files, and that they include a reference to the source location at the time they were built. I bet that if you remove the .pyc files and let them get re- generated the problem will go away. Is there a way to make the stacktraces point to where Python is running from, instead of where it was built? But the stack trace doesn't point to where Python is running from, it points to where the module is. Since you're (probably) running from a compiled module, the location of the .pyc file is useless, and you need to know where the .py file is. But how can the .pyc file know where the .py file is at runtime unless it is cached at compile time? I suppose Python could use some sort of heuristic to guess, but that would be slow and error-prone. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
