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