linecache vs egg - reading line of a file in an egg

R. Bernstein rocky at panix.com
Sun Dec 21 05:07:18 EST 2008


Robert Kern <robert.kern at gmail.com> writes:

> R. Bernstein wrote:
>> Does linecache work with source in Python eggs? If not, is it
>> contemplated that this is going to be fixed or is there something else
>> like linecache that currently works?
>
> linecache works with eggs and other zipped Python source, but it had
> to extend the API in order to do so. Some of the debuggers don't use
> the extended API. This will be fixed in the next 2.6.x bugfix release,
> but not in 2.5.3.

Ok. I have committed a change in pydb sources to deal with the 2 and 3
argument linecache.getline interface which should cover Python
releases both before and after version 2.5.

>
> http://bugs.python.org/issue4201

Many thanks! I should have dug deeper myself.

For pdb/bdb though isn't there still a problem in reporting the file
location? There is that weird "build" name that seems to be stored in
func_code.co_filename mentioned in the original post. 

I just tried patching pdb/bdb along from the current 2.6 svn sources
and here is what I see:

  $ pdb /tmp/lc.py 
  > /tmp/lc.py(1)<module>()
  -> import tracer
  (Pdb) s
  --Call--
  > /src/external-vcs/python/build/bdist.linux-i686/egg/tracer.py(6)<module>()

The above filename is wrong. It's very possible I did something wrong,
so I'd be grateful if someone else double checked. 

Furthermore, if there is a problem I'm not sure I see how to fix this. 

I can think of heuristics to tell if module lives an inside an egg,
but is there a reliable way? Is there a standard convention for
reporting a file location inside of an egg? 

Thanks again.

>
> -- 
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
>  that is made terrible by our own mad attempt to interpret it as though it had
>  an underlying truth."
>   -- Umberto Eco



More information about the Python-list mailing list