[Python-Dev] [PEP 558] thinking through locals() semantics
On Thu, 30 May 2019 at 09:12, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
> > 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 .
> I get the impression that was done because everyone involved
> thought it wasn't worth the ugliness of maintaining all the
> fast/locals swapping stuff, not because of any principle that
> the current behaviour is right or better in any way.
You may have felt that way, but I certainly don't - routinely hiding
function local rebinding from the compiler (and type checkers, and
human readers) is awful, and a privilege that should be reserved to
debuggers and other tools operating at a similar level of "able to
interfere with the normal runtime execution of a program". (Module and
class namespaces are different - they're inherently mutable shared
namespaces as far as the Python runtime is occurred, so locals()
providing one more way of getting a reference to them isn't that big
of a deal - if it's a problem, you can just push the code where you
need to avoid those semantics matters down into a helper function)
So for me, getting rid of write backs via exec and "import *" was a
matter of "Yay, we finally closed those unfortunate loopholes" rather
than being any kind of regrettable necessity.
It's likely also a factor that Python 2.2.2 was the first version of
Python that I ever used extensively, so the existing snapshot-like
behaviour of locals() is the behaviour that feels normal to me, and
I'm somewhat mystified by the notion that anyone might actually *want*
it to behave differently (except to close the remaining loopholes that
still allowed mysterious implicit mutation of previously created
The only rationale for considering that possibility seems to be "It
would make function namespaces behave more like class and module
namespaces", to which my response is "Why would you even want that,
and what practical benefit would it bring to justify the otherwise
gratuitous compatibility break?"
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia