On Wed, 29 May 2019 at 16:08, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > > Nick Coghlan wrote: > > Having a single locals() call de-optimize an entire function would be > > far from ideal. > > I don't see what would be so bad about that. The vast majority > of functions have no need for locals().
If there was a compelling use case for letting "a = 1; exec(src); print(a)" print something other than "1" at function scope, then I'd be more amenable to the idea of the associated compatibility break and potential performance regression in other implementations. However, there isn't any such use case - if there were, we wouldn't have deliberately changed the semantics from the old Python 2 ones to the current Python 3 ones in PEP 3100 [1]. It's also worth noting that the "no backwards compatibility guarantees" wording is only in the help() text, and not in https://docs.python.org/3/library/functions.html#locals - the latter just notes that writing back to it may not work, not that the semantics may arbitrarily change between CPython versions. I think the [snapshot] approach is a solid improvement over my initial proposal, though, since removing the "locals() must always return the same mapping object" requirement also makes it possible to remove some oddities in the fastlocalsproxy implementation, and Nathaniel makes a compelling case that in the areas where the status quo and the snapshot proposal differ, those differences mostly either don't matter, or else they will serve make code otherwise subject to subtle bugs in tracing mode more correct. Cheers, Nick. [1] "exec as a statement is not worth it -- make it a function" in https://www.python.org/dev/peps/pep-3100/#core-language -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
