Getting better traceback info on exec and execfile - introspection?

[R. Bernstein]

In doing the extension to the python debugger which I have here:
  http://sourceforge.net/project/showfiles.php?group_id=61395&package_id=175827
I came across one little thing that it would be nice to get done better.

I notice on stack traces and tracebacks, an exec or execfile command
appears as a stack entry -- probably as it should since it creates a
new environment.

However the frame information for exec or execfile looks like this: 
  File "<string>", line 1, in ?

Okay, the "line 1" probably changes, but most of the time it's going
to be one.  And in code that's in CVS (cvsview:
http://cvs.sourceforge.net/viewcvs.py/bashdb/pydb/) you'll see that
instead of this I now put some thing like:

  ## 1  in exec '<string>' at line 1

which is perhaps is a little more honest since one is not really in a
file called <string>. However the way the debugger gets this *is*
still a little hoaky in that it looks for something in the frame's
f_code.co_filename *called* <string>. And from that it *assumes* this
is an exec, so it can't really tell the difference between an exec
command an execfile command, or a file called <string>. But I suppose
a little more hoakiness *could* be added to look at the outer frame
and parse the source line for "exec" or "execfile".

And suppose instead of '<string>' I'd like to give the value or the
leading prefix of the value instead of the unhelpful word '<string>'?
How would one do that? Again, one way is to go into the outer frame
get the source line (if that exists), parse that and interpolate
argument to exec(file). Is there are better way?

Another and perhaps more direct way to distinguish exec/execfile might
be to some how look at the byte code of the frame entry and decode
that. It also could be used for example in another place in the
debugger where one wants to skip over executing "def" statements (not
the function invocation, but the statement which adds the
function/method so it can get called). But depending on how things are
done unless there are nice version-independent and
implementation-independent symbolic definitions for exec_opcode,
execfile_opcode and def_opcode, although straight-forward and reliable
for a given version/implementation it might not be a good thing to do.

Any help, thoughts or pointers?