On Sun, Sep 11, 2016 at 11:05 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 11 September 2016 at 07:26, Guido van Rossum <gu...@python.org> wrote: > > On Sat, Sep 10, 2016 at 10:57 AM, Nick Coghlan <ncogh...@gmail.com> > wrote: > >> On 11 September 2016 at 03:08, Guido van Rossum <gu...@python.org> > wrote: > >>> So I'm happy to continue thinking about this, but I expect this is not > >>> such a big deal as you fear. Anyway, let's see if someone comes up > >>> with a more convincing argument by beta 2! > >> > >> For CPython specifically, I don't have anything more convincing than > >> Ethan's Enum example (where the way the metaclass works means most of > >> the interesting attributes don't live directly in the class dict, they > >> live in private data structures stored in the class dict, making > >> "list(MyEnum.__dict__)" inherently uninteresting, regardless of > >> whether it's ordered or not). > > > > But that would only matter if we also defined a helper utility that > > used __definition_order__. I expect that the implementation of Enum > > could be simplified somewhat in Python 3.6 since it can trust that the > > namespace passed into __new__ is ordered (so it doesn't have to switch > > it to an OrderedDict in __prepare__, perhaps). > > > > In any case the most likely way to use __definition_order__ in general > > was always to filter its contents through some other condition (e.g. > > "isn't a method and doesn't start with underscore") -- you can do the > > same with keys(). Classes that want to provide a custom list of > > "interesting" attributes can provide that using whatever class method > > or attribute they want -- it's just easier to keep those attributes > > ordered because the namespace is always ordered. > > For example,it's already possible to expose order information via > __dir__, consumers of the information just have to bypass the implicit > sorting applied by the dir() builtin: > > >>> class Example: > ... def __dir__(self): > ... return "first second third fourth".split() > ... > >>> dir(Example()) > ['first', 'fourth', 'second', 'third'] > >>> Example().__dir__() > ['first', 'second', 'third', 'fourth'] > > You've persuaded me that omitting __definition_order__ is the right > thing to do for now, so the last thing I'm going to do is to > explicitly double check with the creators of a few interesting > alternate implementations (MicroPython, VOC for JVM environments, > Batavia for JavaScript environments) to see if this may cause them > problems in officially implementing 3.6 (we know PyPy will be OK, > since they did it first). > > VOC & Batavia *should* be OK (worst case, they return > collections.OrderedDict from __prepare__ and also use it for __dict__ > attributes), but I'm less certain about MicroPython (since I don't > know enough about how its current dict implementation works to know > whether or not they'll be able to make the same change PyPy and > CPython did) > >From the perspective of VOC and Batavia: As Nick notes, there may be some changes needed to use OrderDict (or a native analog) in a couple of places, but other than that, it doesn’t strike me as a change that will pose any significant difficulty. Yours, Russ Magee %-)
_______________________________________________ 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
