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

[Eric Snow]

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
> __definition_order__?

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