[Python-Dev] PEP 520: Ordered Class Definition Namespace (original) (raw)

Eric Snow ericsnowcurrently at gmail.com
Thu Jun 16 13:46:25 EDT 2016

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 definitionorder 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.

More information about the Python-Dev mailing list