Suggested test snippet:

run = 1
timeTaken = 33
r = (22, run, run != 1 and "s" or "", timeTaken)
assert r == (22, 1, '', 33)

On rustpython, this now gives: (1, False, '', 33).

Alright, it's taken me a while to fully grasp the issue, but I think I've got it.

Usually, when and short-circuits, it leaves a value on the stack, because it doesn't need to think about what's on the rhs. However, when and and is the lhs of an or, the or gives the short-circuit label to be the beginning of the rhs of the or, which doesn't expect a value to be on the stack, because when or doesn't short-circuit it pops the value off the stack before moving to the rhs (wrong, I only just fully understood it while typing this out). Basically, in that weird case we jump straight from the lhs of the and to the rhs of the or, and the rhs doesn't expect the lhs to leave a value on the stack. It's hard to tell just in compile_test whether or not we should pop a value off the stack before leaving the lhs of an and, because if we we're jumping from the lhs of the and to the end of the subexpression it should leave a value on the stack, but when we're jumping to the rhs of the or it shouldn't.

Do you have any ideas for how to tackle this @windelbouwman? Maybe a flag in EvalContext::Expression?

No, I don't think an extra flag is a good option. Basically, the switch on EvalContext is the flag. In the case of EvalContext::Statement, there must be no expression left on the stack, in the case of EvalContext::Expression, there must be a single value on the stack, which caused the True or False result.

I do not have a good solution for this, except that I would try to first think of all the different test cases, and really write them out. Only then we might get the logic right, if we cover all combinations. I think it's about 8 different combinations, so we should do this first.

Btw, the longer I look at this compile_test function, the more issues I see.

For example:

If you set both true_label and false_label, in the EvalContext::Statement case, the stack is potentially popped twice.

I can have a look at it if you like? I looked at the CPython sourcecode, I think we can get ideas from there. I'll check micropython as well how they did it.

Sorry about leaving this mess. I got stuck on these bugs and decided to take a break and come back to it (which never happened).

@cthulahoops no problem! All will be fine :).

Okay, I got a pretty good idea about how to solve this. Will open another pull request.

I'll close this, then. :)

@coolreader18 did you intend to merge this? Or close this pull request?

Whoops, I meant to close it. I'll undo it.