rocky bernstein <ro...@gnu.org> added the comment: > > Martin v. Löwis <mar...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue4725> > _______________________________________ > > _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4725> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
