A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2008-December/084592.html below:

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

[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?Nick Coghlan ncoghlan at gmail.com
Tue Dec 23 23:29:36 CET 2008
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 - 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.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4