bpo-40222: update doc entry with respect to the change in WITH_EXCEPT… #29975
Conversation
| items on the stack as arguments. | ||
| Used to implement the call ``context_manager.__exit__(*exc_info())`` when an exception | ||
| has occurred in a :keyword:`with` statement. | ||
|
|
||
| .. versionadded:: 3.9 | ||
| .. versionchanged:: 3.11 | ||
| The ``__exit__`` function is in position 8 of the stack rather than 7. |
There was a problem hiding this comment.
Amazing. What is in positions 4-7, and how does that compare to what was in positions 4-6 before?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| items on the stack as arguments. | ||
| Used to implement the call ``context_manager.__exit__(*exc_info())`` when an exception | ||
| has occurred in a :keyword:`with` statement. | ||
|
|
||
| .. versionadded:: 3.9 | ||
| .. versionchanged:: 3.11 | ||
| The ``__exit__`` function is in position 8 of the stack rather than 7. |
There was a problem hiding this comment.
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.
…_START
https://bugs.python.org/issue40222