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

[Eric Snow]

Thanks for raising these good points, Nikita.  I'll make sure the PEP
reflects this discussion.  (inline responses below...)

-eric

On Tue, Jun 14, 2016 at 3:41 AM, Nikita Nemkin <nikita at nemkin.ru> wrote:
> Is there any rationale for rejecting alternatives like:
>
> 1. Adding standard metaclass with ordered namespace.
> 2. Adding `namespace` or `ordered` args to the default metaclass.

We already have a metaclass-based solution: __prepare__().
Unfortunately, this opt-in option means that the definition order
isn't preserved by default, which means folks can't rely on access to
the definition order.  This is effectively no different from the
status quo.

Furthermore, there's a practical problem with requiring the use of
metaclasses to achieve some particular capability: metaclass
conflicts.  PEPs 422 and 487 exist, in large part, as a response to
specific feedback from users about problems they've had with
metaclasses.  While the key objective of PEP 520 is preserving the
class definition order, it also helps make it less necessary to write
a metaclass.

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

This is a great idea.  I'd support any effort to do so.  But keep in
mind that how we derive __definition_order__ isn't as important as
that it's always there.  So the use of OrderedDict for the
implementation isn't necessary.  Instead, it's the implementation I've
taken.  If we later switch to using the compiler to get the definition
order, then great!

> ?
>
> To me, any of the above seems preferred to complicating
> the core part of the language forever.

What specific complication are you expecting?  Like nearly all of
Python's "power tools", folks won't need to know about the changes
from this PEP in order to use the language.  Then when they need the
new functionality, it will be ready for them to use.  Furthermore, as
far as changes to the language go, this change is quite simple and
straightforward (consider other recent changes, e.g. async).  It is
arguably a natural step and fills in some of the information that
Python currently throws away.  Finally, I've gotten broad support for
the change from across the community (both on the mailing lists and in
personal correspondence), from the time I first introduced the idea
several years ago.

>
> The vast majority of Python classes don't care about their member
> order, this is minority use case receiving majority treatment.

The problem is that there isn't any other recourse available to code
that wishes to determine the definition order of an arbitrary class.
This is an obstacle to code that I personally want to write (hence my
interest).

>
> Also, wiring OrderedDict into class creation means elevating it
> from a peripheral utility to indispensable built-in type.

Note that as of 3.5 CPython's OrderedDict *is* a builtin type (though
exposed via the collections module rather than the builtins module).
However, you're right that this change would mean OrderedDict would
now be used by the interpreter in all implementations of Python 3.6+.
Some of the other implementators from which I've gotten feedback have
indicated this isn't a problem.