[Python-Dev] PEP 520: Ordered Class Definition Namespace

[Eric Snow]

On Thu, Jun 16, 2016 at 5:11 AM, Nikita Nemkin <nikita at nemkin.ru> wrote:
> I'll reformulate my argument:
>
> Ordered class namespaces are a minority use case that's already covered
> by existing language features (custom metaclasses) and doesn't warrant
> the extension of the language (i.e. making OrderedDict a builtin type).
> This is about Python-the-Language, not CPython-the-runtime.

So your main objection is that OrderedDict would effectively become
part of the language definition?  Please elaborate on why this is a
problem.

> The simple answer is "don't do that", i.e. don't pile an ordered metaclass
> on top of another metaclass. Such use case is hypothetical anyway.

It isn't hypothetical.  It's a concrete problem that folks have run
into enough that it's been a point of discussion on several occasions
and the motivation for several PEPs.

> All explicit assignments in the class body can be detected statically.
> Implicit assignments via locals(), sys._frame() etc. can't be detected,
> BUT they are unlikely to have a meaningful order!
> It's reasonable to exclude them from __definition_order__.

Yeah, it's reasonable to exclude them.  However, in cases where I've
done so I would have wanted them included in the definition order.
That said, explicitly setting __definition_order__ in the class body
would be enough to address that corner case.

>
> This also applies to documentation tools. If there really was a need,
> they could have easily extracted static order, solving 99.9999% of
> the problem.

You mean that they have the opportunity to do something like AST
traversal to extract the definition order?  I expect the definition
order isn't important enough to them to do that work.  However, if the
language provided the definition order to them for free then they'd
use it.

>
>> The rationale for "Why not make this configurable, rather than
>> switching it unilaterally?" is that it's actually *simpler* overall to
>> just make it the default - we can then change the documentation to say
>> "class bodies are evaluated in a collections.OrderedDict instance by
>> default" and record the consequences of that, rather than having to
>> document yet another class customisation mechanism.
>
> It would have been a "simpler" default if it was the core dict that
> became ordered. Instead, it brings in a 3rd party (OrderedDict).

Obviously if dict preserved insertion order then we'd use that instead
of OrderedDict.  There have been proposals along those lines in the
past but at the end of the day someone has to do the work.  Since we
can use OrderedDict right now and there's no ordered dict in sight, it
makes the choice rather easy. :)  Ultimately the cost of defaulting to
OrderedDict is not significant, neither to the language definition nor
to run-time performance.  Furthermore, defaulting to OrderedDict (per
the PEP) makes things possible right now that aren't otherwise a
possibility.

>
>> It also eliminates boilerplate from class decorator usage
>> instructions, where people have to write "to use this class decorator,
>> you must also specify 'namespace=collections.OrderedDict' in your
>> class header"
>
> Statically inferred __definition_order__ would work here.
> Order-dependent decorators don't seem to be important enough
> to worry about their usability.

Please be careful about discounting seemingly unimportant use cases.
There's a decent chance they are important to someone.  In this case
that someone is (at least) myself. :)  My main motivation for PEP 520
is exactly writing a class decorator that would rely on access to the
definition order.  Such a decorator (which could also be used
stand-alone) cannot rely on every possible class it might encounter to
explicitly expose its definition order.

-eric