<div dir="ltr">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. :-)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 23, 2015 at 7:38 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 24 May 2015 at 12:04, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> On 24 May 2015 at 11:15, Eric Snow <<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>> wrote:<br>
>> tl;dr Are there any objections to making making the default<br>
>> cls.__prepare__ return OrderedDict instead of dict (and preserve that<br>
>> order in a list on the class)?<br>
>><br>
>> A couple years ago [1][2] I proposed making class definition<br>
>> namespaces use OrderedDict by default.  Said Guido [3]:<br>
>><br>
>>     I'm fine with doing this by default for a class namespace; the type of<br>
>>     cls.__dict__ is already a non-dict (it's a proxy) and it's unlikely to<br>
>>     have 100,000 entries.<br>
>><br>
>> It turns out making cls.__dict__ an OrderedDict isn't reasonably<br>
>> tractable (due to the concrete API v. subclasses), but really that<br>
>> isn't what I was looking for anyway.<br>
>><br>
>> Regardless, since it's been a while I just want to run the proposal by<br>
>> the group again.  I'm hopeful about landing my C implementation of<br>
>> OrderedDict [4] in the next few days.  Also, I have a patch up [5]<br>
>> that implements using OrderedDict for class definitions.  So mostly I<br>
>> just want to double check that I'm still good to go.<br>
><br>
> While it isn't controversial (since you already have the +1 from<br>
> Guido), it's worth writing up the change as a PEP for 3.6 anyway,<br>
> since that then provides clearer guidance to alternate implementations<br>
> that they're going to need to change the way their class namespace<br>
> evaluation works for 3.6.<br>
<br>
</span>Eric clarified for me that Larry was considering granting a feature<br>
freeze exemption to defer landing this to beta 2 while Eric tracked<br>
down a segfault bug in the current patch that provides a C<br>
implementation of OrderedDict. That sounds like a nicer approach than<br>
what I did for PEP 489 (where I checked in an initial version that I<br>
knew still had a refleak bug in it), so +1 from me for going down that<br>
path.<br>
<br>
A top level section in the What's New would cover my concerns<br>
regarding making sure folks are suitably aware of the change (as I<br>
believe leaving it out of the original 2.6 What's New document was the<br>
real problem with making people aware of the addition of zip archive<br>
and directory execution support).<br>
<br>
Regards,<br>
<div class="HOEnZb"><div class="h5">Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>