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

[Steve Holden]

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/