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