Re: Patch: Update RuleDispatch for python-2.7
"P.J. Eby" <pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]> Mon, 02 Aug 2010 02:33:34 -0400
| Newsgroups | gmane.comp.python.peak |
|---|---|
| Message-ID | <[email protected]> |
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).