Hi Nick, hi List, thanks for the good comments! I'll update the PEP and the implementation soon, as discussed at the end, I'll do it in C this time. For now just some quick responses:
> This part isn't entirely clear to me, so you may want to give some > Python pseudo-code that: I will actually give the actual code, it's just 10 lines, that should be understandable. > - is explicit regarding exactly when this new code runs in the type > creation process > - whether the __set_owner__ hooks are called before or after > __init_subclass__ runs, or only when the subclass calls up to > super().__init_subclass__, and the implications of each choice (either > descriptors see a partially initialised class object, or init_subclass > sees partially initialised descriptor objects, or that choice is > delegated to individual subclasses) > - how the list of objects to be checked for "__set_owner__" methods is > retrieved (presumably via "ns.items()" on the class definition > namespace, but the PEP should be explicit) > > For the second point, my personal preference would be for descriptors > to have their owner set first and independently of __init_subclass__ > super calls (as it seems more likely that __init_subclass__ will > depend on having access to fully initialised descriptors than the > other way around). I intuitively programmed it the other way around, but I get your point and will change it. I agree that it should not be done in super().__init_subclass__ as people often forget to call it, or do weird things. > Honestly though, I'm not sure this additional user-visible complexity > is worth it - "The default type metaclass has this new behaviour" is a > lot easier to document and explain than "We added a new opt-in > alternate metaclass that you can use if you want, and in the next > version that will just become an alias for the builtin types again". > We'd also end up being stuck with types.Type and types.Object as > aliases for the type and object builtins forever (with the associated > "How does 'class name:' or 'class name(object)' differ from 'class > name(types.Object)'?" question and "It doesn't, unless you're using > Python 3.6" answer for folks learning the language for the first > time). My idea with a stepped approach was to have a chance to look how people use the feature, so that when we make it standard eventually we actually get it right. In the end, this is a maintainability question. I am fully OK with following experienced core developers here, so if the general idea here is that a two-step approach is not needed, then no problem, let's do it in the Python core directly! Greetings Martin _______________________________________________ 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
