[PEAK] Patch: Update RuleDispatch for python-2.7
pje at telecommunity.com
Mon Aug 2 02:33:34 EDT 2010
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',
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).
More information about the PEAK