In disassembled code of Python functions I often see stuff like this:

            421 JUMP_IF_FALSE           14 (to 438)
            424 POP_TOP

1178        ...
            435 JUMP_FORWARD             1 (to 439)
        >>  438 POP_TOP
        >>  439 END_FINALLY

Note how both branches of execution after JUMP_IF_FALSE do POP_TOP.  This causes the true-branch add JUMP_FORWARD, the only purpose of which is to bypass the POP_TOP command.

I propose adding two new bytecodes, JUMP_IF_FALSE_AND_POP and JUMP_IF_TRUE_AND_POP.  Their semantics would be the same as that of existing JUMP_IF_FALSE/JUMP_IF_TRUE except the commands would also pop the stack once, after checking whether to jump.  This would simplify the above code to just

            421 JUMP_IF_FALSE_AND_POP           14 (to 438)

1178        ...
        >>  438 END_FINALLY

This shortens bytecode by 5 bytes and both execution branches, by 1 and 2 commands correspondingly.

I'm willing to create a patch, if this sounds like a worthwile improvement.  Maybe it is better to skip 2.6 and target it for 3000 instead.

I have made first stab at this.  It shows about 2% speedup on pystone, even though peephole optimizer does no related optimizations for new bytecodes yet.

Note that having separate entries in ceval.c's switch() for the new bytecodes is essential.  Perhaps because they are also used for prediction, not sure.

File Added: new-bytecodes.diff

This was looked at and rejected long ago.
The main reasons were that the new code would interfere with and complicate other byte code optimizations.  Also, the need was mitigated almost entirely by the predict macros.