On 10 September 2016 at 19:27, Nick Coghlan <ncogh...@gmail.com> wrote: > On 10 September 2016 at 17:49, Ethan Furman <et...@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 | 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/archive%40mail-archive.com