On 6/17/06, Armin Rigo [EMAIL PROTECTED] wrote:
The reason is that the details of the stack behavior of END_FINALLY are
messy in CPython. The finally blocks are the only place where the depth
of the stack is not known in advance: depending on how the finally block
is entered, there will be
At 11:23 AM 6/18/2006 -0700, Guido van Rossum wrote:
I'm not in favor of abusing this to generate a computed goto, and I
don't see a need for that -- if we decide to add that (either as
syntax or as an automatic optimization) I see no problem adding a new
bytecode.
Me either -- I suggest simply
Hi Phillip,
On Fri, Jun 16, 2006 at 10:01:05PM -0400, Phillip J. Eby wrote:
One thing I'm curious about, if there are any PyPy folks listening: will
tricks like this drive PyPy or Psyco insane? :)
Yes, both :-)
The reason is that the details of the stack behavior of END_FINALLY are
messy in
At 01:18 PM 6/17/2006 +0200, Armin Rigo wrote:
Psyco cheats here and emulates a behavior where there is
always exactly one object instead (which can be a tuple), so if a
END_FINALLY sees values not put there in the official way it will just
crash. PyPy works similarily but always expect three
For folks contemplating what opcodes might need to be added to implement a
switch statement, it turns out that there is a clever way (i.e. a
filthy hack) to implement computed jumps in Python bytecode, using
WHY_CONTINUE and END_FINALLY.
I discovered this rather by accident, while working on