[Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

Eric Snow ericsnowcurrently at gmail.com
Tue Jun 28 13:30:37 EDT 2016


On Sun, Jun 26, 2016 at 5:55 PM, Guido van Rossum <guido at python.org> wrote:
>> On Fri, Jun 24, 2016 at 4:37 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> > This version looks fine to me.
>
> Same to me, mostly.

I've updated the PEP per everyone's comments [1], except I still
haven't dropped the read-only __definition_order__ constraint.  I'll
do that when I resolve the open questions, on which I'd like some
feedback:

* What about __slots__?

  In addition to including __slots__ in __definition_order__, the
options I see are to either ignore the names in __slots__, put them
into __definition_order__ right after __slots__, or stick them in at
the end (since their descriptors are added afterward).  I'm leaning
toward the first one, leaving the slot names out of
__definition_order__ since the
names aren't actually part of the definition (__slots__ itself is).
Doing so doesn't lose any information and more closely reflects the
class definition body.

* Allow setting __definition_order__ in type()?

I don't see any reason to disallow "__definition_order__" in the
namespace passed in to the 3 argument form of builtins.type().  Then
dynamically created types can have a definition order (without needing
to set cls.__definition_order__ afterward).

* C-API for setting __definition_order__?

I'd rather avoid any extra complexity in the PEP due to diving into
C-API support for *creating* types with a __definition_order__.
However, if it would be convenient enough and not a complex endeavor,
I'm willing to accommodate that case in the PEP.  At the same time, at
the C-API level is it so important to accommodate
__definition_order__ at class-creation time?  Can't you directly
modify cls.__dict__ in C?  Perhaps it would be safer to have a simple
C-API function to set __definition_order__ for you?

* Drop the "read-only attribute" requirement?

I really like that read-only implies "complete", which is a valuable
message for __definition_order__ to convey.  I think that there's a
lot to be said for communicating about a value in that way.

At the same time, most of the time Python doesn't keep you from
fiddling with similar "complete" values (e.g. __name__, __slots__), so
I see that point too.  And since the interpreter (nor stdlib) doesn't
rely on __definition_order__, it isn't much of a footgun (nor would
setting __definition_order__ be much of an attractive nuisance).

I suppose I'm having a hard time letting go of the attractiveness of
"read-only == complete".  However, given that you've been pretty clear
what you think, I'm more at ease about it. :)

Anyway, thoughts on the above would be helpful.  I'll try to be
responsive so we can wrap this up.

-eric


[1] https://github.com/python/peps/blob/master/pep-0520.txt


More information about the Python-Dev mailing list