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

[Guido van Rossum]

On Tue, Jun 28, 2016 at 10:30 AM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> 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.

Sounds fine. I guess this means you don't have to do anything special, right?

> * 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).

Right.

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

What's the use case even? I think if __definition_order__ is writable
then C code can just use PyObject_SetAttrString(<class_object>,
"__definition_order__", <some_tuple>).

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

But it's still unique behavior, and it's not needed to protect CPython
internals.

> 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. :)

Yeah, it's time to drop 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



-- 
--Guido van Rossum (python.org/~guido)