[Python-Dev] PEP520 and absence of __definition_order__

[Guido van Rossum]

Thanks for bringing this up. I think it's definitely possible to argue
either way. I think what happened before was that I approved
__definition_order__ because I wasn't expecting dict to be ordered by
default. Now that Inada Naoki's patch has landed things have changed.

Here's my reason for agreeing with (or convincing?) Eric to drop
__definition_order__, as I remember it from the (lively) discussion at
the sprint.

- There are only a few use cases for definition order. Without trying
to be complete, the use cases I am aware of are all similar to the
django Forms interface
(https://docs.djangoproject.com/en/1.10/ref/forms/api/#module-django.forms)
where the order in which fields are defined determines the order in
which they are rendered. Possibly the traits or traitlets libraries
also have similar functionality; I know I added it to a database API I
wrote at Google as well. I have another idea for a use case where you
can define a named tuple with typed fields using PEP 526 syntax.

- I like sparsity of interfaces. A class already has dunder attributes
for bases, mro, docstring, name, qualified name, module, and probably
a few others that I've forgotten. Cruft inevitably accumulates, but I
still feel I have to fight it. If we can get the functionality needed
for those use cases without a new dunder attribute, so much the
better.

- The Forms trait[let]s use cases and named tuples can clearly be
dealt with by using list(cls.__dict__), since they all involve a
user-defined class.

- If we had had ordered dicts from the start, those use cases would
have been built upon that happily. What would Cython do? I don't know,
but  I imagine they'd come up with it -- they certainly ought to be
able with a way to construct the class __dict__ in the desired order.
Is there even a situation where Cython would need to support the
construction of forms, trait[let]s, or named tuples using Cython code
in a way that the order is discoverable afterwards? (I imagine that
Cython would love the named tuple idea, but they'd know the field
definition order at compile time, so why would they also need it at
runtime?)

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!

--Guido

On Sat, Sep 10, 2016 at 4:19 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 10 September 2016 at 19:27, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On 10 September 2016 at 17:49, Ethan Furman <ethan at stoneleaf.us> wrote:
>>> The "mostly" is what concerns me.  Much like having a custom __dir__ lets
>>> a class fine-tune what is of interest, a custom __definition_order__ allows
>>> a class to present a unified view of the class creation process.  This could
>>> be important to classes that employ __getattr__ (or __getattribute__) to
>>> provide virtual attributes, such as Enum or proxy classes.
>>
>> +1
>>
>> The reasoning for modifying the PEP post-acceptance is faulty -
>> __definition_order__ wasn't just there as a CPython implementation
>> detail, it was there as a way to allow class and metaclass developers
>> to hide their *own* irrelevant implementation details.
>>
>> Since __definition_order__ was already accepted, and the rationale for
>> removing it is incorrect, could we please have it back for beta 1?
>
> After posting this, I realised I should give a bit more detail on why
> I see PEP 520 without __definition_order__ as potentially problematic.
> Specifically, it relates to these two sections in the PEP about having
> __definition_order__ be writable and about whether or not to set it
> for classes that aren't created via the class syntax:
>
> * https://www.python.org/dev/peps/pep-0520/#why-not-a-read-only-attribute
> * https://www.python.org/dev/peps/pep-0520/#support-for-c-api-types
>
> From the first section: "Also, note that a writeable
> __definition_order__ allows dynamically created classes (e.g. by
> Cython) to still have __definition_order__ properly set. That could
> certainly be handled through specific class- creation tools, such as
> type() or the C-API, without the need to lose the semantics of a
> read-only attribute. However, with a writeable attribute it's a moot
> point. "
>
> From the second: "However, since __definition_order__ can be set at
> any time through normal attribute assignment, it does not need any
> special treatment in the C-API."
>
> Unlike the __definition_order__ tuple, making "list(cls.__dict__)" the
> official way of accessing the definition order exposes an
> implementation detail that's somewhat specific to the way Python class
> statements work, rather than being universal across all the different
> techniques that exist for putting together Python class objects.
>
> As Terry suggested, I've reopened and elevated the priority of
> http://bugs.python.org/issue24254, but only to deferred blocker -
> while I do think we need to reconsider the decision to remove
> __definition_order__ based on a proper update to the PEP that accounts
> for all the points that came up in the original discussions, I also
> don't see any major problem with leaving it out in beta 1, and then
> restoring it in beta 2.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at 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)