Paul Sokolovsky <pfal...@users.sourceforge.net> added the comment:
> Paul: you're are in front of 3 core developers who are rejecting your feature > request. But no, it's not my feature request. There were 2 tickets by at least 2 people. I just saw my case to be similar to cases of those people, so instead of creating duplicate bug reports, I chimed in, to show the general issue: various name-related opcodes don't treat namespace objects consistently. And if I'm in front on 3 core developers here, then only because someone's Rubber Ducky (https://en.wikipedia.org/wiki/Rubber_duck_debugging) took a good vacation. Because I may imagine following "debugging session": - Hey Ducky, some time ago I hacked on one project. As you know, I'm a core developer, so I kinda can add things on my whim, so I added some stuff to CPython core for that project, not consistent, not complete. Since then, I lost interest in my project, and as you can imagine, couldn't care less about the code in the core. The problem? It was almost 8 years ago. People discovered those features, and came to use on them. Not only that, they raise heads and demand it to be implemented more thoroughly and consistently. So, don't you think now would be good time to punish them and just rip that code out? - You say how could I possible to do that on my own? No worries, I have 2 more buddies vouching for me, we core developers never let each other down. - You're saying that removing features after 8 years is problematic? No worries, we can always say it was a regression from just 3 years ago. - Hey Ducky, there's a more problem still, there's a particularly obnoxious dude, who initially tried to argue need for adding a feature based on my 8-year old code. If we support stuff in LOAD_GLOBAL, he says, then it should be piece of cake to support it in STORE_GLOBAL, which is called much less frequently. But we got him into the cold with a news of removal that 8-year code. Still he can't calm down, and changing tactics arguing that due to the way that globals are used at the module level (as locals too), then STORE_GLOBAL should behave consistently with STORE_NAME, tossing some pretty simple exec() code showing inconsistency. Should we just ignore him, or go for total punishment and make it "consistent" just the same as above, by removing support in STORE_NAME, instead of adding to STORE_GLOBAL? Now, that code is 16 years old. Do you think we can go for a twist like that? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32615> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
