bpo-40222: update doc entry with respect to the change in WITH_EXCEPT… by iritkatriel · Pull Request #29975 · python/cpython

the-knights-who-say-ni


		.. versionadded:: 3.9
		.. versionchanged:: 3.11
		The ``__exit__`` function is in position 8 of the stack rather than 7.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing. What is in positions 4-7, and how does that compare to what was in positions 4-6 before?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment next to the opcode in ceval.c spells it out. Used to be exit, tb, val, exc, tb, val, exc (two exceptions). Now it's exit, lasti, tb, val, exc, tb, val, exc. because the previous exceptions needs to know what the last line was. This lasti business was added with zero-cost exceptions, I'm not totally clear about when it is or is not there.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I wonder why we bother to document these opcodes when the documentation is so blatantly insufficient. :-(

FWIW that comment in the code is not great either -- "Then we push again the TOP exception and the __exit__ return value." But TOP was never popped, so we really only push the return value. I'm guessing you will soon change this again so that there are just two exception objects on the top of the stack.

(I find the opcode name also odd. Why START when it calls __exit__?)

Anyway. Ignore me.


		.. versionadded:: 3.9
		.. versionchanged:: 3.11
		The ``__exit__`` function is in position 8 of the stack rather than 7.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I wonder why we bother to document these opcodes when the documentation is so blatantly insufficient. :-(

(I find the opcode name also odd. Why START when it calls __exit__?)

Anyway. Ignore me.