[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)

Steve Holden steve at holdenweb.com
Wed Dec 24 05:37:13 CET 2008

R. Bernstein wrote:

Nick Coghlan writes: > R. Bernstein wrote: > > Nick Coghlan writes: > > > 3. Do what a number of standard library APIs (e.g. linecache) that > > > accept filenames do and also accept an optional "module globals" > > > argument. > > > > Actually, I did this and committed a change (to pydb) before posting > > any of these queries. ;-) > > > > If "a number of standard library APIs" are doing the same thing, > > then shouldn't this exposed as a common routine? > > > > If on the other hand, by "a number" you mean "one" as in linecache -- > > 1 is a number too! -- then perhaps the relevant code that is buried > > inside the "updatecache" should be exposed on its own. (As a side > > benefit that code can be tested separately too!) > > > > Should I file a feature request for this? > > The reason for my slightly odd phrasing is that all of the examples I > was originally going to mention (traceback, pdb, doctest, inspect) > actually all end up calling linecache to do the heavy lifting. > > So it is possible that linecache.getlines() actually is the common > routine you're looking for

I never asked about getting the text lines for the source code, no matter how many times people suggest that as an alternative. :-) Instead, I was asking about a common way to get information about the source location for say a frame or traceback object (which might include package name and type) and suggest that there should be a more unambiguous way to display this information than seems to be in use at present. I agree. Since PEP 302 many parts of Python are rather too file-centric for my liking. I notes almost four years ago, for example, that the interpreter assumes that the os module will be imported from filestore in order to set the prefix. This issue appears to have received no attention since, and I'm certainly not the one with the best skills or knowledge to solve this problem.

http://bugs.python.org/issue1116520

Part of work to retrieve or displaying that information has to do the some of the same things that is inside of linecache.updatecache() before it retrieves the lines of the source code (when possible). And possibly parts of it include parts of what's done in pieces of the inspect module.

> - it just needs to be added to the > documentation and the all attribute for linecache to be officially > supported. Currently, only the single line getline() function is > documented and exposed via all, but I don't see any reason for that > restriction - linecache.getlines() has been there with a stable API > since at least Python 2.5. > > For cases where you have an appropriate Python object (i.e. a module, > function, method, class, traceback, frame or code object) rather than a > pseudo-filename, then inspect.getsource() actually jumps through a lot > of hoops to try to find the actual source code for that object - in > those cases, using the appropriate inspect function is generally a much > better idea than trying to interpret file yourself. > > Cheers, > Nick. Thanks for the information. I will keep in mind those inspect routines. They probably will be a helpful for another problem I had been wondering about -- how one can determine if there is no code associated at a given a line and file. (In other words and invalid location for a debugger line breakpoint, such as because the line part of a comment or the interior line of a string that spans many lines) Looks like that start of some necessary attention to this issue. The inspect module might indeed offer the right facilities. I'm still wondering what we do about the various prefix settings in an environment where there are no filestore imports at all.

In the event I can assist feel free to rope me in.

regards Steve

Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

More information about the Python-Dev mailing list