[Python-Dev] PEP520 and absence of __definition_order__

[Nick Coghlan]

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