[Python-Dev] PEP 487: Simpler customization of class creation

[Martin Teichmann]

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