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