On 24/05/15 10:35, Nick Coghlan wrote: > On 24 May 2015 at 15:53, Eric Snow <ericsnowcurrently at gmail.com> wrote: >> >> On May 23, 2015 10:47 PM, "Guido van Rossum" <guido at python.org> wrote: >>> >>> How will __definition_order__ be set in the case where __prepare__ doesn't >>> return an OrderedDict? Or where a custom metaclass's __new__ calls its >>> superclass's __new__ with a plain dict? (I just wrote some code that does >>> that. :-) >> >> I was planning on setting it to None if the order is not available. At the >> moment that's just a check for OrderedDict. > > Is it specifically necessary to save the order by default? Metaclasses > would be able to access the ordered namespace in their __new__ method > regardless, and for 3.6, I still like the __init_subclass__ hook idea > proposed in PEP 487, which includes passing the original namespace to > the new hook. > > So while I'm sold on the value of making class execution namespaces > ordered by default, I'm not yet sold on the idea of *remembering* that > order without opting in to doing so in the metaclass. > > If we leave __definition_order__ out for the time being then, for the > vast majority of code, the fact that the ephemeral namespace used to > evaluate the class body switched from being a basic dictionary to an > ordered one would be a hidden implementation detail, rather than > making all type objects a little bigger. and a little slower. Cheers, Mark.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4