[Python-Dev] PEP487: Simpler customization of class creation

[Martin Teichmann]

Hi Guido, Hi list,

Thanks for the nice review! I applied followed up your ideas and put
it into a github pull request: https://github.com/python/peps/pull/53

Soon we'll be working there, until then, some responses to your comments:

> I wonder if this should be renamed to __set_name__ or something else
> that clarifies we're passing it the name of the attribute? The method
> name __set_owner__ made me assume this is about the owning object
> (which is often a useful term in other discussions about objects),
> whereas it is really about telling the descriptor the name of the
> attribute for which it applies.

The name for this has been discussed a bit already, __set_owner__ was
Nick's idea, and indeed, the owner is also set. Technically,
__set_owner_and_name__ would be correct, but actually I like your idea
of __set_name__.

> That (inheriting type from type, and object from object) is very
> confusing. Why not just define new classes e.g. NewType and NewObject
> here, since it's just pseudo code anyway?

Actually, it's real code. If you drop those lines at the beginning of
the tests for the implementation (as I have done here:
https://github.com/tecki/cpython/blob/pep487b/Lib/test/test_subclassinit.py),
the test runs on older Pythons.

But I see that my idea to formulate things here in Python was a bad
idea, I will put the explanation first and turn the code into
pseudo-code.

>>         def __init__(self, name, bases, ns, **kwargs):
>>             super().__init__(name, bases, ns)
>
> What does this definition of __init__ add?

It removes the keyword arguments. I describe that in prose a bit down.

>>     class object:
>>         @classmethod
>>         def __init_subclass__(cls):
>>             pass
>>
>>     class object(object, metaclass=type):
>>         pass
>
> Eek! Too many things named object.

Well, I had to do that to make the tests run... I'll take that out.

>> In the new code, it is not ``__init__`` that complains about keyword arguments,
>> but ``__init_subclass__``, whose default implementation takes no arguments. In
>> a classical inheritance scheme using the method resolution order, each
>> ``__init_subclass__`` may take out it's keyword arguments until none are left,
>> which is checked by the default implementation of ``__init_subclass__``.
>
> I called this out previously, and I am still a bit uncomfortable with
> the backwards incompatibility here. But I believe what you describe
> here is the compromise proposed by Nick, and if that's the case I have
> peace with it.

No, this is not Nick's compromise, this is my original. Nick just sent
another mail to this list where he goes a bit more into the details,
I'll respond to that about this topic.

Greetings

Martin

P.S.: I just realized that my changes to the PEP were accepted by
someone else than Guido. I am a bit surprised about that, but I guess
this is how it works?