Getting better traceback info on exec and execfile - introspection?

[Fernando Perez]

R. Bernstein wrote:

> Fernando Perez <fperez.net at gmail.com> writes:
>> R. Bernstein wrote:
> ...
>> > However the frame information for exec or execfile looks like this:
>> >   File "<string>", line 1, in ?
>> 
>> That comes from how the code object was compiled:
> ...
>> So any regexp-matching based approach here is likely to be fairly
>> brittle, unless you restrict your tool to the standard python
>> interpreter, and you get some guarantee that it will always tag
>> interactive code with '<string>'.
> 
> Thanks for the information! Alas, that's bad news. The question then
> remains as to how to accurately determine if a frame is running an
> exec operation and accurately get the string associated with the exec.
> 
> Given all the introspection about python's introspection, it should be
> possible.

I thought a little about this.  One possibility would be to check whether
the argument given in the string exists as a file; if not, assume it's a
string.  I can't think of another way, since the string given is completely
arbitrary.  But someone who knows more about the internal structure of code
objects may give you better tips.

> I also tried pydb.py using IPython 0.7.0 (using an automatically
> updated Fedora Core 5 RPM) and although I was expecting pydb.py breakage
> from what you report, I didn't find any difference.
> 
> 
> % ipython
> Python 2.4.2 (#1, Dec 17 2005, 13:02:22)
> Type "copyright", "credits" or "license" for more information.
> 
> IPython 0.7.0 -- An enhanced Interactive Python.
> ?       -> Introduction to IPython's features.
> %magic  -> Information about IPython's 'magic' % functions.
> help    -> Python's own help system.
> object? -> Details about 'object'. ?object also works, ?? prints more.
> 
> In [1]: %run /usr/lib/python2.4/site-packages/pydb.py test1.py
>> /home/rocky/python/test1.py(2)?()
> -> import sys
> (Pydb) where
> -> 0  in file '/home/rocky/python/test1.py' at line 2
> ## 1  in exec cmd in globals, locals at line 1
> ## 2  run() called from file '/usr/lib/python2.4/bdb.py' at line 366
> (Pydb)
> 
> Note entry ##1 is *not*
>   File "<string>", line 1, in ?
> 
> So somehow I guess ipython is not intercepting or changing how compile
> was run here.

Oh, that's because you're using %run, so your code is in complete control. 
What I meant about a restriction was thiking about using your pydb as the
debugger called by ipython when exceptions occur.

Try

%pdb

and then %run any script with an error in it, to be dropped in post-mortem
mode inside the stack.  That uses an ipython-enhanced pdb, but not your
pydb.  As your code matures and improves, it would be nice to, for example,
make it possible to plug it into ipython as a 'better debugger'.  But
there, you'll see '<ipython console>' as the filename markers.

Anyway, good luck with this.  If you are interested in ipython integration,
I suggest the ipython-dev list as a better place for discussion: I only
monitor c.l.py on occasion, so I may well miss things here.

Regards,

f