| msg78203 - (view) |
Author: rocky bernstein (rocky) |
Date: 2008-12-22 17:56 |
| 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. |
|
|
| msg78220 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2008-12-23 00:16 |
| 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). |
|
|
| msg78221 - (view) |
Author: rocky bernstein (rocky) |
Date: 2008-12-23 02:25 |
| > > 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> > _______________________________________ > > |
|
|
| msg78227 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2008-12-23 08:39 |
| > 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. |
|
|