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

[Nick Coghlan]

On 14 June 2016 at 02:41, Nikita Nemkin <nikita at nemkin.ru> wrote:
> Is there any rationale for rejecting alternatives like:

Good questions - Eric, it's likely worth capturing answers to these in
the PEP for the benefit of future readers.

> 1. Adding standard metaclass with ordered namespace.

Adding metaclasses to an existing class can break compatibility with
third party subclasses, so making it possible for people to avoid that
while still gaining the ability to implicitly expose attribute
ordering to class decorators and other potentially interested parties
is a recurring theme behind this PEP and also PEPs 422 and 487.

> 2. Adding `namespace` or `ordered` args to the default metaclass.

See below (as it relates to your own complexity argument)

> 3. Making compiler fill in __definition_order__ for every class
>     (just like __qualname__) without touching the runtime.
> ?

Class scopes support conditionals and loops, so we can't necessarily
be sure what names will be assigned without running the code. It's
also possible to make attribute assignments via locals() that are
entirely opaque to the compiler, but visible to the interpreter at
runtime.

> To me, any of the above seems preferred to complicating
> the core part of the language forever.
>
> The vast majority of Python classes don't care about their member
> order, this is minority use case receiving majority treatment.
>
> Also, wiring OrderedDict into class creation means elevating it
> from a peripheral utility to indispensable built-in type.

Right, that's one of the key reasons this is a PEP, rather than just
an item on the issue tracker.

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 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"

Folks that don't need the ordering information do end up paying a
slight import time and memory cost, which is another key reason for
handling the proposal as a PEP rather than just as a tracker issue.

Aside from the boilerplate reduction when used in conjunction with a
class decorator, a further possible category of consumers would be
documentation generators like pydoc and Sphinx apidoc, which may be
able to switch to displaying methods in definition order, rather than
the current approach of always listing them in alphabetical order.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia