[Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)
Guido van Rossum
guido at python.org
Tue Jun 28 13:43:18 EDT 2016
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 , 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
> * 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).
> * 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>,
> * 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
> 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.
>  https://github.com/python/peps/blob/master/pep-0520.txt
--Guido van Rossum (python.org/~guido)
More information about the Python-Dev