I know you don't disagree with the patch being rejected, but I have to say that the reviewer gave you a firm example in which your patch changes expected behavior.
Philosophy aside, that is a fine reason to reject the patch unless you can convince the reviewer (and the committee) that you are in the right (you very well may be).
Yes, I agree that the patch was wrong in that it shouldn't optimize NAME/GLOBAL. I was unaware of those semantics when I wrote it. However that doesn't apply to FAST, the most common LOAD/STORE ops. The other reasons are why the patch wouldn't be accepted if it were fixed
Also, just want to also say Python reviewers are great. They're very good at explaining issues with patches & are willing to collaborate on improving a patch when necessary. There's a long list of backlog issues because there is simply not enough review to go around, not because of a lack of quality. Highly recommend CPython to people who want to get involved in contributing to an open source project, even just testing patches helps
Being in the right is very much a matter of taste. Python has always erred on the side o less optimization and more obvious behavior. So something that optimizes for performance while introducing subtle possibilities for bugs would likely be accepted by the C++, but not the Python commitee.
And I think that's ok. Python wants to be simple and straightforward and performance was never a goal.
If you need performance don't use Python, or write a python library in C/C++/Rust and do the heavy lifting there.
Philosophy aside, that is a fine reason to reject the patch unless you can convince the reviewer (and the committee) that you are in the right (you very well may be).