[Python-Dev] PEP: Ordered Class Definition Namespace

[Eric Snow]

On Tue, Jun 7, 2016 at 2:34 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 06/07/2016 02:20 PM, Eric Snow wrote:
>> I think both of those make __definition_order__ more complicated and
>> less useful.  As the PEP stands, folks can be confident in what
>> __definition_order__ represents.  What would you consider to be the
>> benefit of a mutable (or replaceable) __definition_order__ that
>> outweighs the benefit of a simpler definition of what's in it.
>
> I think the question is which is more useful?
>
> - a definition order that lists items that are not in the class, as
>   well as not having items that are in the class (set by the decorator)
>
> or
>
> - a definition order that is representative of the class state after
>   all decorators have been applied

"definition" refers explicitly to the execution of the class body in a
class statement.  So what you've described is a bit confusing to me.
If we're talking about some other semantics then the name
"__definition_order__" is misleading.

Also, consider that __definition_order__ is, IMHO, most useful when
interpreted as the actual order of attributes in the class definition
body.  The point is that code outside the class body can leverage the
order of assigned names within that block.  So, relative to the class
definition, I'm not clear on valid use cases that divorce themselves
from the class definition, such that either of your scenarios is
relevant.

Semantics that relate more to the class namespace (__dict__) are a
separate matter from this PEP.  I'd welcome a broader solution that
still met the needs at which __definition_order__ is aiming.  For
example, consider if the class's __dict__ (or rather the proxied
value) were OrderedDict.  In fact, Guido was originally (in 2013)
amenable to that idea.  However, I tried it and making it work was a
challenge due to use of the concrete dict C-API.  I'd be glad if it
was worked out.  In the meantime, this PEP is more focused on a
practical representation of the ordering information inside just the
class definition body.

>
> One argument for the latter is that, even though the class has been
> technically "defined" (class body executed, type.__new__ called, etc.),
> applying decorators feels like continued class definition.

Perhaps.  That doesn't align with my intuition on decorators, but I'll
readily concede that my views aren't always particularly
representative of everyone else. :)  That said, there are many
different uses for decorators and modifying the class namespace
(__dict__) isn't the only one (and in my experience not necessarily
the most common).

>
> One argument for the former is simplified implementation,

I'm not sure what you're implying about the implementation.  Do you
mean that it's easier than just letting __definition_order__ be
writable (or mutable)?  It's actually slightly more work to make it a
read-only attr.  Perhaps you mean that the semantics in the PEP are
easier to implement than something that tracks changes to the class
namespace (__dict__) after definition is over?  Probably, though I
don't see anything like that happening (other than if OrderedDict were
used for __dict__).

> and is definition
> order really important after the class body has been executed?  (okay, two
> arguments ;)

Given that the focus is on class definition, I'd argue no. :)

>
> Perhaps the best thing is just to make it writeable -- after all, if
> __class__, __name__, etc., can all be changed, why should
> __definition_order__ be special?

Not all attrs are writable and it's a case-by-case situation: some of
the ones that are writable started out read-only and changed once
there was a valid reason.  If anything, it's arguably safer in general
to take an immutable-by-default approach.

-eric