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.

Author rocky
Recipients rocky
Date 2008-12-22.17:56:23
SpamBayes Score 1.4389434e-11
Marked as misclassified No
Message-id <1229968585.58.0.896136373006.issue4725@psf.upfronthosting.co.za>
In-reply-to
Content
When listing a traceback or showing stack frames or implementing a
debugger (or a tool which wants to track the exact location of the
source code), how is one supposed to detect a file located inside an egg
or some other archive mechanism? 

There are a number of issues, I think. First, I think some sort of
consistent naming convention would be helpful. 

Here's an example of the current situation. I have a file called
tracer.py inside egg
/usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/tracer.py
and I get an exception inside of that. The traceback shows this:

   File "build/bdist.linux-i686/egg/tracer.py", line 216, in size

The file information comes from frame.f_code.co_filename and its
relation to a file is a bit nebulous since there is no file either in
the filesystem with that path suffix nor a file in an with that name.
(It's possible there was a file with that suffix at one time during the
build of the egg.)

So possibly this is a bug.

Via the __loader__ key in the tracer module's __dict__ hash (a 
zipimporter object) there is a _files hash which has a key "tracer.py"
with value
"/usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/tracer.py".
This seems to correspond to a file tracer.py in zip file:
/usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg 

Glomming the two parts together as one entity or one name is a bit weird
and means that things that work on files will have do some parsing to
figure out that this there is a member inside an archive (and egg here). 

PEP 302 has lots of interesting things in it such as a way to get the
file source text, but it doesn't specify uniform file *names* of either
the surrounding package/archive or the member inside that.

So possibly this is an omission or something that should be added.

Finally looking at linecache.py, the function update_cache() has a
routine to do some sort of filename resolution consulting loaders using
the API of PEP 302. Possibly the name resolution part (without reading
file data) might be made callable by itself so that it returns a
package/archive name and a package/archive member name.
History
Date User Action Args
2008-12-22 17:56:25rockysetrecipients: + rocky
2008-12-22 17:56:25rockysetmessageid: <1229968585.58.0.896136373006.issue4725@psf.upfronthosting.co.za>
2008-12-22 17:56:24rockylinkissue4725 messages
2008-12-22 17:56:23rockycreate