[PEAK] Patch: Update RuleDispatch for python-2.7

[P.J. Eby]

At 01:32 AM 8/2/2010 -0400, Toshio Kuratomi wrote:
>One slight problem we've run into is that we can't currently get
>python-peak-rules running on python-2.7 due to incompatibility between the
>current version of python-byte-assembler (which is a peak-rules dependency)
>and python-2.7.  The JUMP_IF_FALSE and FUMP_IF_TRUE opcodes have been
>removed in python-2.7.

Erk.  It looks like they have replaced them with:

'JUMP_IF_FALSE_OR_POP', 'JUMP_IF_TRUE_OR_POP', 'POP_JUMP_IF_FALSE', 
and 'POP_JUMP_IF_TRUE'.

It looks like I'll probably have to implement the 'OR' variants as a 
kind of "macro" for older Pythons, in order to keep code generation 
simple.  But the tests that rely on dumping disassemblies are going 
to break on 2.7, unless I write a replacement disassembler.  Ugh.

I'll post again when it's done, but I'm not sure how long that's 
going to take.  Damn.

Fortunately, between BytecodeAssembler and PEAK-Rules, there are only 
11 references to JUMP_IF opcodes in the code itself (as opposed to 
the tests).  So changing them won't be hard at all, especially since 
only 3 of them aren't immediately followed by a POP_TOP.  It's what 
to do with those three that'll be tougher.

Hm.  I suppose I could always implement the old opcodes as a macro 
that sticks in a DUP_TOP and then uses the unconditional POP 
forms...  That would be evil, performance-wise on 2.7, but it'd make 
those weird cases easier and transparently support old 
code.  Hm...  I actually kinda like that.  Anybody else using 
BytecodeAssembler will then get 2.7-compatibility for free, at the 
expense of a little slowdown on conditional jumps; if they want the 
performance, they can upgrade to one of the newer opcodes (and still 
have it work with older Pythons).