[Python-Dev] PEP520 and absence of definition_order (original) (raw)
Guido van Rossum guido at python.org
Sat Sep 10 13:08:19 EDT 2016
- Previous message (by thread): [Python-Dev] PEP520 and absence of __definition_order__
- Next message (by thread): [Python-Dev] PEP520 and absence of __definition_order__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 definitionorder 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 - definitionorder 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 definitionorder 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 definitionorder as potentially problematic. Specifically, it relates to these two sections in the PEP about having definitionorder 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 definitionorder allows dynamically created classes (e.g. by Cython) to still have definitionorder 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 definitionorder can be set at any time through normal attribute assignment, it does not need any special treatment in the C-API." Unlike the definitionorder 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 definitionorder 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)
- Previous message (by thread): [Python-Dev] PEP520 and absence of __definition_order__
- Next message (by thread): [Python-Dev] PEP520 and absence of __definition_order__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]