bytecode JUMP_IF_* always followed by POP_TOP?

[Tim Peters]

[Robert Brewer]
> Playing around with bytecodes some more:
> ...
> I notice that, whether JUMP_IF_FALSE jumps or not, the next
> instruction it executes is POP_TOP
> ...
> Are there any constructions whereby this does not happen for
> JUMP_IF_FALSE and JUMP_IF_TRUE?

Try

    x and y

and

    x or y

When those jump, they want to retain the tested value, so there's no POP_TOP
at the branch target then.

> If there aren't, is it just explicitness that kept JUMP_IF_* from
> doing the POP on its own, before the jump (which would thereby save
> two instructions)?

Explicitness has little to do with the byte codes.  It would probably be
better if the JUMP_IF_* opcodes consumed the tested value, and codegen for
"and" and "or" (which are rarer) pumped out an extra DUP_TOP.  In all the
years that's been suggested <wink>, though, nobody has cared enough to
bother making the change.