Internal Debugger Question

[Lothar Scholz]

Hello,

i'm currently writing a debugger for python and found that some
modules store an absolute file path in "co_filename" of there
methods/functions and some store a relative file path. Because the
relative file path can never be expanded to an absolute file path
later (the sys.path may have changed) it is impossible to find the
source code location.

Is there anything i have missed or is this simply a bug. I would
highly recommend to fix this bug !

 

[Duncan Booth]

(e-mail address removed) (Lothar Scholz) wrote in

i'm currently writing a debugger for python and found that some
modules store an absolute file path in "co_filename" of there
methods/functions and some store a relative file path. Because the
relative file path can never be expanded to an absolute file path
later (the sys.path may have changed) it is impossible to find the
source code location.

Is there anything i have missed or is this simply a bug. I would
highly recommend to fix this bug !

Are you running Python 2.3, if not you should upgrade as the behaviour has
changed? The only relative paths I can see are for the script itself. Other
modules, even when loaded through a relative path store the absolute value
of the name.

Before trying to use the stored filename, remember that as of Python 2.3
you can have custom loaders, so the 'filename' might not refer to a path at
all (although the loader might have a get_source method to help you).

Even if it does refer to a path, the path might not be valid when you come
to use it, if for example it was a path to a network drive which is no
longer accessible. I think the best you can do in this situation is to try
to use the path information you are given, and if you can't find a suitable
source file either prompt the user or just give up.

 

[Lothar Scholz]

(e-mail address removed) (Lothar Scholz) wrote in


Are you running Python 2.3, if not you should upgrade as the behaviour has
changed? The only relative paths I can see are for the script itself. Other
modules, even when loaded through a relative path store the absolute value
of the name.

Yes i'm using Python 2.3 and Webware on Win32. As far as i have seen
it there is no custom loader in Webware but the paths for all the base
classes are relative paths. The path for user defined Python Server
Pages and Servelets are absolute - this is the strange thing. I
remember that there was a problem with 2.2 so i hoped all this was
gone.

Even if it does refer to a path, the path might not be valid when you come
to use it, if for example it was a path to a network drive which is no
longer accessible. I think the best you can do in this situation is to try
to use the path information you are given, and if you can't find a suitable
source file either prompt the user or just give up.

Yes but i don't think anyone change network drives when debugging an
application. And if the network has problems it is time for a cup of
coffee instead of further debugging.

 

[Michael Hudson]

i'm currently writing a debugger for python and found that some
modules store an absolute file path in "co_filename" of there
methods/functions and some store a relative file path. Because the
relative file path can never be expanded to an absolute file path
later (the sys.path may have changed) it is impossible to find the
source code location.

Is there anything i have missed or is this simply a bug. I would
highly recommend to fix this bug !

I belive this is one of the oldest open bug reports on SF... I spent a
few minutes looking at it, before deciding I didn't care enough to fix
it. Your point of view may be different:

http://python.org/sf/415492

Be warned, the import code is some of the most frightening (to me,
anyway) code in Python.

Cheers,
mwh

 

[Just]

I belive this is one of the oldest open bug reports on SF... I spent a
few minutes looking at it, before deciding I didn't care enough to fix
it. Your point of view may be different:

http://python.org/sf/415492

Be warned, the import code is some of the most frightening (to me,
anyway) code in Python.

A workaround may be to look at __file__ in the frame's f_globals field.
I'm moderately confident that that one gets set correctly upon import.

Just