<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, May 24, 2015 at 1:36 PM, Eric Snow <span dir="ltr"><<a href="mailto:ericsnowcurrently@gmail.com" target="_blank">ericsnowcurrently@gmail.com</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><p dir="ltr"><br>
On May 24, 2015 3:35 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com" target="_blank">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>
</span><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><span class="HOEnZb"><font color="#888888">

</font></span></blockquote></div><br></div><div class="gmail_extra">Let's table it. It's hard to compare alternatives on a single dimension of "which is a bigger change".<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>