[Python-Dev] PyEval_GetFrame() revisited

[Fred L. Drake, Jr.]

Christian Tismer writes:
 > Hi there!

Good afternoon!

 > here has been this patch to the threadstate, which
 > allows to override the tstate's frame access.
...
 > Reason why I'm thinking about this:
 > In order to simplify Stackless, I thought to remove
 > the frame variable, and let it be accessed always
 > via my current tasklet, which holds the frame.
 > 
 > Looking for the number of necessary patches, I stumbled
 > over PyExpat, and thought I should better keep my
 > hands off. Too bad.
 > 
 > Does it make sense to think about an API for
 > modifying the frame? Or are we at a dead end here?

What's being modified isn't the frame but the tstate, but it may be
reasonable to provide some API to manipulate the "current" frame.

I think pyexpat is unique in doing this, but it actually makes a lot
of sense; there are other modules for which a similar behavior is
likely to be appropriate (one example I can think of is Fredrik's
sgmlop module).

What pyexpat is trying to achieve is fairly simple, and I don't think
there's a better way currently.  When Python code calls the Parse() or
ParseFile() method of a parser object (returned from
pyexpat.ParserCreate()), the parser can generate many different
callbacks into Python code.  pyexpat generates an artificial code
object and frame that can be used to generate more useful tracebacks
when exceptions are raise within callbacks; the code object indicates
which callback Expat triggered, separately from the function assigned
to handle that callback.  This makes it much easier to debug handler
functions.

If there were API functions to get/set the frame, pyexpat wouldn't
need to poke into the tstate at all.  Would that alleviate the
difficulties this creates for Stackless / Psycho?


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation