On Tue, Jun 28, 2016 at 10:30 AM, Eric Snow
On Sun, Jun 26, 2016 at 5:55 PM, Guido van Rossum
wrote: On Fri, Jun 24, 2016 at 4:37 PM, Nick Coghlan
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(
* 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
-- --Guido van Rossum (python.org/~guido)