Hello Guido, On Thu, May 13, 2004 at 09:51:54AM -0700, Guido van Rossum wrote: > > * 'finally' blocks are executed with one, two or three values pushed > > on the stack; END_FINALLY will accordingly pop one, two or three > > values (depending on what the first popped value is). > > This is easily fixed, if necessary -- but is it necessary? It is a minor inconvenience for analysis tools. They more or less have to consider that within a finally block the structure of the stack is initially unknown (but contains at most N values, for some N) and that no opcode is allowed to peek or modify this unknown portion of the stack until END_FINALLY is reached. Psyco is an example of tool which assumes that the stack depth is only dependent on the bytecode position, and has a couple of hacks to deal with finally blocks. > > * POP_BLOCK will empty the value stack up to the position stored in > > the block stack's popped block, for no reason that I am aware of. > > I can't remember what my intention was; I probably wasn't so sure that > the stack level at the end of executing arbitrary code was always > the same. I guess it should be reviewed and removed. > > ... A better 'fix' would be that the block > > stack could, as we discussed at PyCon, be replaced by a purely > > static structure in the code object. > > Correct, I would like to see this happen. There's dynamic stuff here > just to make the implementation easy rather than to support necessary > dynamism. (The same could be said of some other parts of Python, but > there we've come to love the dynamism -- for the most part anyway. ;-) I'd like to give it a try, but I'd like to see if someone has any idea about the kind of structure that we are looking for here. I was roughly thinking about a binary tree, but we need something more compact than a naive tree. Armin
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