On Fri, Jun 10, 2016 at 11:29 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 10 June 2016 at 09:42, Eric Snow <ericsnowcurren...@gmail.com> wrote: >> On Thu, Jun 9, 2016 at 2:39 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >>> That restriction would be comparable to what we do with __slots__ today: >>> >>> >>> class C: >>> ... __slots__ = 1 >>> ... >>> Traceback (most recent call last): >>> File "<stdin>", line 1, in <module> >>> TypeError: 'int' object is not iterable >> >> Are you suggesting that we require it be a tuple of identifiers (or >> None) and raise TypeError otherwise, similar to __slots__? The >> difference is that __slots__ has specific type requirements that do >> not apply to __definition_order__, as well as a different purpose. >> __definition_order__ is about preserving definition-type info that we >> are currently throwing away. > > If we don't enforce the tuple-of-identifiers restriction at type > creation time, everyone that *doesn't* make it a tuple-of-identifiers > is likely to have a subtle compatibility bug with class decorators and > other code that assume the default tuple-of-identifiers format is the > only possible format (aside from None). To put it in PEP 484 terms: > regardless of what the PEP says, people are going to assume the type > of __definition_order__ is Optional[Tuple[str]], as that's going to > cover almost all class definitions they encounter. > > It makes sense to me to give class definitions and metaclasses the > opportunity to change the *content* of the definition order: "Use > these names in this order, not the names and order you would have > calculated by default". > > It doesn't make sense to me to give them an opportunity to change the > *form* of the definition order, since that makes it incredibly > difficult to consume correctly: "Sure, it's *normally* a > tuple-of-identifiers, but it *might* be a dictionary, or a complex > number, or a set, or whatever the class author decided to make it". > > By contrast, if the class machinery enforces Optional[Tuple[str]], > then it becomes a lot easier to consume reliably, and anyone violating > the constraint gets an immediate exception when defining the offending > class, rather than a potentially obscure exception from a class > decorator or other piece of code that assumes __definition_order__ > could only be None or a tuple of strings.
That makes sense. I'll adjust the PEP (and the implementation). -eric _______________________________________________ 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
