<p dir="ltr"><br>
On May 24, 2015 3:35 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> Is it specifically necessary to save the order by default? Metaclasses<br>
> would be able to access the ordered namespace in their __new__ method<br>
> regardless, and for 3.6, I still like the __init_subclass__ hook idea<br>
> proposed in PEP 487, which includes passing the original namespace to<br>
> the new hook.<br>
><br>
> So while I'm sold on the value of making class execution namespaces<br>
> ordered by default, I'm not yet sold on the idea of *remembering* that<br>
> order without opting in to doing so in the metaclass.<br>
><br>
> If we leave __definition_order__ out for the time being then, for the<br>
> vast majority of code, the fact that the ephemeral namespace used to<br>
> evaluate the class body switched from being a basic dictionary to an<br>
> ordered one would be a hidden implementation detail, rather than<br>
> making all type objects a little bigger.</p>
<p dir="ltr">It's too late for 3.5 to negotiate much so I'll try to make my case here for __definition_order__ one last time.   If that's not sufficient then I'll defer further discussion to 3.6.</p>
<p dir="ltr">My premise for storing the definition order on the class is that Guido was okay with using OrderedDict for cls.__dict__, which is a bigger change.  Regardless, there are two reasons why it makes sense:</p>
<p dir="ltr">* If it makes sense to use OrderedDict by default for class definition then it makes sense to preserve the extra information OrderedDict provides.<br>
* As I noted at the beginning of the thread, you could still preserve that info manually, but that makes it less convenient for library authors.</p>
<p dir="ltr">If you still think that's not enough justification then we can table __definition_order__ for now.</p>
<p dir="ltr">-eric</p>