R. Bernstein wrote: > Fernando Perez <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
