In fact, that's exactly how Python implements UNARY_NEGATIVE: https://github.com/python/cpython/blob/v3.9.0/Python/ceval.c#L1538 https://github.com/python/cpyth

In fact, that's exactly how Python implements UNARY_NEGATIVE: https://github.com/python/cpython/blob/v3.9.0/Python/ceval.c#L1538 https://github.com/python/cpython/blob/v3.9.0/Python/ceval.c... If you look a bit further down in the original article, you'll see that the BINARY_ADD instruction does something similar. It pops (a pointer to) the first operand, and modifies (a pointer to) the second one in-place. Semantically, it makes sense to define operations as popping the operand(s) and pushing a result, for simplicity. But there's no reason the interpreter has to actually be implemented that way, as long as the observable behavior is the same. In any case, I wouldn't be surprised if an extra push/pop ended up having very little performance impact. The compiler might be able to optimize away the pointer increment/decrement instructions, and if not, the stack pointer is pretty much guaranteed to be in the L1 cache.