On Sun, Jun 26, 2016 at 5:55 PM, Guido van Rossum <gu...@python.org> wrote: >> On Fri, Jun 24, 2016 at 4:37 PM, Nick Coghlan <ncogh...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
