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.

If this message is about multiple issues (as the second paragraph
suggests), they should be reported separately. As it stands, this is too
much text for me to consider, and it might be too much for other readers
as well. When you split it up, please consider whether the things are
bugs or wishes, and whether they apply to Python proper, or some other
library (e.g. setuptools - eggs are not part of Python).

> 
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
> If this message is about multiple issues (as the second paragraph
> suggests), they should be reported separately. As it stands, this is too
> much text for me to consider, and it might be too much for other readers
> as well. 

Fair enough. So let's start with I guess the most important thing. 

PEP 302 describes an importer protocol. Given that, I don't understand
how I can reliably get full (package) information about where the
source code resides from a stack frame or code object. For code that
comes from packages like eggs (but not necessarily restricted to eggs
as there may be other packaging mechanisms), the information would
contain the package file
(e.g. /usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg), a
member inside that (e.g. tracer.py), and possibly loader/packaging
information (e.g. zipimporter).

For a specific mechanism like zipimporter, no doubt one can hack
something based on how the package mechanism is currently
implemented. But given there is an API for import hooks that package
mechanisms currently adhere to, shouldn't there also be some sort of API
for untangling what has gone on? 

A use case here is in a stack trace or a debugger where an error
occured. For example does this come from an egg? And if so, which one? 

Perhaps I have missed something in PEP 302, or perhaps this is defined
elsewhere. Please elucidate.


> When you split it up, please consider whether the things are
> bugs or wishes, and whether they apply to Python proper, or some other
> library (e.g. setuptools - eggs are not part of Python).

Ok. I'll probably add one more "bug" report for now see where things
go. Based on the outcome of these queries, I'll possibly add more. The
problem I have with splitting things up too soon is that I'm not sure
where the problem lies.

As stated above, I think the crux is that given that there are now
package mechanisms that bundle source code into a file, the notion of
a "file" location should be adjusted to include the package and/or
importer. If it turns out that there already is this notion, then it
could be that certain implementations aren't aware of it and/or don't
adhere to it.

> 
> ----------
> nosy: +loewis
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue4725>
> _______________________________________
> 
>

> A use case here is in a stack trace or a debugger where an error
> occured. For example does this come from an egg? And if so, which one? 
> 
> Perhaps I have missed something in PEP 302, or perhaps this is defined
> elsewhere. Please elucidate.

Please understand that the bug tracker is not a place to ask questions,
or get help. If you make a bug report, *ALWAYS* follow this pattern:

1. this is what I did
2. this is what happened
3. this is what I would have expected instead

If you want to get help in doing something that you don't know how to
do, or need elucidation, use python-list@python.org. If you are
proposing a new feature, and want to discuss the design of it, use
python-dev@python.org; you might be told to write a PEP if the feature
is more complex.

I'm going to close this report as invalid.