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
