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