[Python-Dev] [PEP 558] thinking through locals() semantics

[Nick Coghlan]

On Wed, 29 May 2019 at 16:08, Greg Ewing <greg.ewing at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia