Thanks for writing this up, Nick! My main question is about the remaining difference between semantics at the class/module versus function level: is it worth the additional cognitive complexity to have the class/module behavior be different from the function behavior?
The "mutable" class/module behavior is really nice for debuggers, of course, but when you want that you really want it at *all* scopes, so having it available only some of the time feels like an unpredictable tool. I could imagine having a mode where everything (including function scopes) is required to permit mutability, but that would (a) be a lot of work (as you pointed out in the design discussion) and (b) would cause "debug mode" binaries to have to work so differently from "opt mode" ones that debugging would get harder for other reasons. I'm not sure that it *isn't* worth it to have this extra flexibility at the higher scope levels, but it isn't obvious to me that it is, and if that could lead to some code simplification, I wouldn't be sad! Yonatan On Mon, Dec 30, 2019 at 10:47 PM Nick Coghlan <ncogh...@gmail.com> wrote: > Hi folks, > > I've finally updated PEP 558 and it's reference implementation based > on Nathaniel's feedback back in May. > > The latest version of the PEP can now be found at > https://www.python.org/dev/peps/pep-0558/, and I've created a > discussion thread on Discourse: > https://discuss.python.org/t/pep-558-defined-semantics-for-locals/2936 > > The latest version implements Nathaniel's "independent snapshot" > proposal, and I like how that has turned out. The one thing that > changed from the May discussion thread is that the refcount semantics > of PyEval_GetLocals() (it returns a borrowed reference) meant that it > had to keep the old behaviour of returning a reference to the internal > dynamically updated shared "snapshot" at function scope, with a new > API, PyEval_GetPyLocals(), providing the C equivalent of the locals() > builtin. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/GHN2GYJQRU77EZBXX4SQUZ5XEMEONSFL/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NH2ILSTNK5KGHAXPT7FUPBQSRJBKQKMW/ Code of Conduct: http://python.org/psf/codeofconduct/
