Antony Lee <anntzer....@gmail.com> added the comment:

> encourage the common assumption that locals() returns a dict where mutating 
> it actually works, since it usually doesn't.

It does at global and class scope, not at function scope.

FWIW, PEP558 (admittedly not accepted yet) proposes to modify the documentation 
for the semantics of locals() at class-scope to match the actual behavior 
(https://www.python.org/dev/peps/pep-0558/#class-scope):

    At class scope [...] changes to the returned mapping must change the values 
bound to local variable names in the execution environment.

> I'm worried that making _EnumDict inherit from collections.abc.MutableMapping 
> in general would slow down Enums (at the very least creation, I'm not clear 
> on whether _EnumDict remains, hidden behind the mappingproxy, for future 
> lookups on the class), since MutableMapping would introduce a Python layer of 
> overhead to most calls.

"Normal" calls won't: __setitem__ / __getitem__ stays what they are, they were 
implemented in Python and stay implemented in Python.  Whoever calls update() 
will go through an extra Python layer, but there's not much you can do about 
that.

Alternatively, if you *really* don't want to support the MutableMapping API, at 
least it should be disabled (e.g. by adding stub implementations of update(), 
etc. that throw NotImplementedError).  Again performance-wise this would only 
affect those who try to call these methods.

As a side note, I would be curious to see any realistic code where the 
performance of enum creation turns out to be critical.  I don't think(?) the 
_EnumDict stays afterwards, at least PEP558 (which supposedly corresponds to 
the actual current behavior) also states "The mapping returned by locals() will 
not be used as the actual class namespace underlying the defined class (the 
class creation process will copy the contents to a fresh dictionary that is 
only accessible by going through the class machinery)."

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to