[Python-Dev] Should there be a way or API for retrieving from a code object a loader method and package file where the code comes from? (original) (raw)

Paul Moore p.f.moore at gmail.com
Tue Dec 23 17:55:36 CET 2008

2008/12/23 R. Bernstein <rocky at panix.com>:

A use case here I am thinking of here is in a stack trace or a debugger, or a tool which wants to show in great detail, information from a code object obtained possibly via a frame object.

Thanks for the clarifications. I see what you're after much better now.

I find it kind of sucky to see in a traceback: "" as opposed to the text (or prefix of the text) of the actual string that was passed. Or something that has been referred to as a "pseudo-file" like /usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/foo/bar.py when it is really member foo/bar.py of zipped egg /usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg.

Fair comment. That points to a "human readable" type of string. It's not available at the moment, but I guess it could be.

But see below.

> - xxx.getsourcecode(token) is a function (I don't know where, > xxx is a placeholder for some "suitable" module) which, given such a > token, returns the source, or None if there's no viable concept of > "the source".

There always is a viable concept of a source. It's whatever was done to get the code. For example, if it was via an eval then the source was the eval function and a string, same for exec. If it's via database access, well that then and some summary info about what's known about that.

Hmm, "source" colloquially, yes "bytecode loaded from ....\xxx.pyc", for example. But not "source" in the sense of "source code". Some applications run with only bytecode shipped, no source code available at all.

There are two problems. One is displaying location information in an unambiguous way -- the pseudo-file above is ambiguous and so is since there's no guarentee that OS's make to not name a file that. The second problem is programmatically getting information such as a debugger or an IDE might do so that the information can be conveyed back to a user who might want to inspect surrounding source code or modules.

This is more than you were asking for above.

The first problem is addressed with a "human readable" (narrative) description, as above.

The second, however, requires machine-readable access to source code (if it exists). That's what the loader get_source() call does for you. But you have to be prepared for the fact that it may not be possible to get source code, and decide what you want to happen in that case.

> I hope this is of some help,

Yes, thanks. At least I now have a clearer idea of the state of where things stand.

Good. Sorry it's not better news :-)

Paul

More information about the Python-Dev mailing list