> 
> 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>
> _______________________________________
> 
>