I found a strange issue with how the interpreter produces bytecode for an expression like True != True in [False, False].

Reading it, one would expect the value of the expression to be True, whether the inequality comparison is evaluated first, or the membership test is evaluated first. Indeed, when parentheses are used to control the order of execution these results do occur.

However, without any parentheses, the result is False. The underlying cause seems to be in a short circuit which is dependent on the inequality comparison, seen in the JUMP_IF_FALSE_OR_POP instruction.

This expression is very synthetic, but I am submitting this bug under the worry that it speaks to a more significant error in the bytecode produced for inequality tests (or membership tests).