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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4