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

[Martin Teichmann]

Hi Guido, Hi Nick, Hi list,

so I just updated PEP 487, you can find it here:
https://github.com/python/peps/pull/57 if it hasn't already been
merged. There are no substantial updates there, I only updated the
wording as suggested, and added some words about backwards
compatibility as hinted by Nick.

Greetings

Martin

2016-07-14 17:47 GMT+02:00 Guido van Rossum <guido at python.org>:
> I just reviewed the changes you made, I like __set_name__(). I'll just
> wait for your next update, incorporating Nick's suggestions. Regarding
> who merges PRs to the PEPs repo, since you are the author the people
> who merge don't pass any judgment on the changes (unless it doesn't
> build cleanly or maybe if they see a typo). If you intend a PR as a
> base for discussion you can add a comment saying e.g. "Don't merge
> yet". If you call out @gvanrossum, GitHub will make sure I get a
> message about it.
>
> I think the substantial discussion about the PEP should remain here in
> python-dev; comments about typos, grammar and other minor editorial
> issues can go on GitHub. Hope this part of the process makes sense!
>
> On Thu, Jul 14, 2016 at 6:50 AM, Martin Teichmann
> <lkb.teichmann at gmail.com> wrote:
>> 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?
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
>
> --
> --Guido van Rossum (python.org/~guido)