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

Eric Snow ericsnowcurrently at gmail.com
Mon Jun 20 22:11:09 EDT 2016

On Mon, Jun 20, 2016 at 10:32 AM, Guido van Rossum <guido at python.org> wrote:

- I don't like the exception for dunder names. I can see that module, name etc. that occur in every class are distractions, but since you're adding methods, you should also add methods with dunder names like init or getattr. (Otherwise, what if someone really wanted to create a Django form with a field named dunder?)

Note that in that case they could set definition_order manually in their class body. That said, I don't mind relaxing this if you think the common-case clutter is worth it for the case where a dunder name is relevant. You have a keen sense for this sort of situation. :)

- It's a shame we can't just make dict (a proxy to) an OrderedDict, then we wouldn't need an extra attribute. Hm, maybe we could customize the proxy class so its keys(), values(), items() views return things in the order of definitionorder?

I'm not sure it's worth it to mess with the proxy like that. Plus, I like how definition_order makes it obvious what it is as well as more discoverable.

(In the tracker discussion this was considered a big deal, but given that a class dict is already a readonly proxy I'm not sure I agree. Or is this about C level access? How much of that would break?)

I actually tried making the underlying class namespace (behind the proxy at dict) an OrderedDict. I ended up with a number of problems because of the pervasive use of the concrete dict API relative to the class dict. That API does not play well with subclasses.

- I don't see why it needs to be a read-only attribute. There are very few of those -- in general we let users play around with things unless we have a hard reason to restrict assignment (e.g. the interpreter's internal state could be compromised). I don't see such a hard reason here.

I'm willing to change that. I figured we would start off treating it like we have other dunder attributes, some of which have become writable while others remain read-only. However, you are right that there is no danger in making it writable.

- All in all the motivation is fairly weak -- it seems to be mostly motivated on avoiding a custom metaclass for this purpose because combining metaclasses is a pain. I realize it's only a small patch in a small corner of the language, but I do worry about repercussions -- it's an API that's going to be used for new (and useful) purposes so we will never be able to get rid of it.

True. It's certainly a very specific feature. The point is that we currently throw away the attribute order from class definitions. You can opt in to preserving the order using an appropriate metaclass. However, everything that would make use of that information (e.g. class decorators) would then have a prerequisite of that metaclass. That means such a tool could only consume classes that were designed to be used by the tool. Then there's the whole problem of metaclass conflicts (see PEP 487).

If, instead, we always preserved the definition order then these problems (again, for an admittedly corner use case) go away.

FWIW, regarding repercussions, I do not expect any other potential future feature will subsume the functionality of PEP 520. The closest thing would be if cls.dict became ordered. However, that would intersect with definition_order only at first. Furthermore, cls.dict would only ever be able to make vague promises about any relationship with the definiton order. The point of definiton_order is to provide the one obvious place to get a specific bit of information about a class.

Note: I'm neither accepting nor rejecting the PEP; I'm merely inviting more contemplation.

Thanks. :)

-eric

More information about the Python-Dev mailing list