<div dir="ltr">Yes, I'm very excited about this!<div><br></div><div>Will this mean no more metaclass conflicts if using @abstractmethod?</div><div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 17, 2016 at 12:59 PM Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This PEP is now accepted for inclusion in Python 3.6. Martin,<br>
congratulations! Someone (not me) needs to review and commit your<br>
changes, before September 12, when the 3.6 feature freeze goes into<br>
effect (see <a href="https://www.python.org/dev/peps/pep-0494/#schedule" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0494/#schedule</a>).<br>
<br>
On Sun, Jul 17, 2016 at 4:32 AM, Martin Teichmann<br>
<<a href="mailto:lkb.teichmann@gmail.com" target="_blank">lkb.teichmann@gmail.com</a>> wrote:<br>
> Hi Guido, Hi Nick, Hi list,<br>
><br>
> so I just updated PEP 487, you can find it here:<br>
> <a href="https://github.com/python/peps/pull/57" rel="noreferrer" target="_blank">https://github.com/python/peps/pull/57</a> if it hasn't already been<br>
> merged. There are no substantial updates there, I only updated the<br>
> wording as suggested, and added some words about backwards<br>
> compatibility as hinted by Nick.<br>
><br>
> Greetings<br>
><br>
> Martin<br>
><br>
> 2016-07-14 17:47 GMT+02:00 Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>>:<br>
>> I just reviewed the changes you made, I like __set_name__(). I'll just<br>
>> wait for your next update, incorporating Nick's suggestions. Regarding<br>
>> who merges PRs to the PEPs repo, since you are the author the people<br>
>> who merge don't pass any judgment on the changes (unless it doesn't<br>
>> build cleanly or maybe if they see a typo). If you intend a PR as a<br>
>> base for discussion you can add a comment saying e.g. "Don't merge<br>
>> yet". If you call out @gvanrossum, GitHub will make sure I get a<br>
>> message about it.<br>
>><br>
>> I think the substantial discussion about the PEP should remain here in<br>
>> python-dev; comments about typos, grammar and other minor editorial<br>
>> issues can go on GitHub. Hope this part of the process makes sense!<br>
>><br>
>> On Thu, Jul 14, 2016 at 6:50 AM, Martin Teichmann<br>
>> <<a href="mailto:lkb.teichmann@gmail.com" target="_blank">lkb.teichmann@gmail.com</a>> wrote:<br>
>>> Hi Guido, Hi list,<br>
>>><br>
>>> Thanks for the nice review! I applied followed up your ideas and put<br>
>>> it into a github pull request: <a href="https://github.com/python/peps/pull/53" rel="noreferrer" target="_blank">https://github.com/python/peps/pull/53</a><br>
>>><br>
>>> Soon we'll be working there, until then, some responses to your comments:<br>
>>><br>
>>>> I wonder if this should be renamed to __set_name__ or something else<br>
>>>> that clarifies we're passing it the name of the attribute? The method<br>
>>>> name __set_owner__ made me assume this is about the owning object<br>
>>>> (which is often a useful term in other discussions about objects),<br>
>>>> whereas it is really about telling the descriptor the name of the<br>
>>>> attribute for which it applies.<br>
>>><br>
>>> The name for this has been discussed a bit already, __set_owner__ was<br>
>>> Nick's idea, and indeed, the owner is also set. Technically,<br>
>>> __set_owner_and_name__ would be correct, but actually I like your idea<br>
>>> of __set_name__.<br>
>>><br>
>>>> That (inheriting type from type, and object from object) is very<br>
>>>> confusing. Why not just define new classes e.g. NewType and NewObject<br>
>>>> here, since it's just pseudo code anyway?<br>
>>><br>
>>> Actually, it's real code. If you drop those lines at the beginning of<br>
>>> the tests for the implementation (as I have done here:<br>
>>> <a href="https://github.com/tecki/cpython/blob/pep487b/Lib/test/test_subclassinit.py" rel="noreferrer" target="_blank">https://github.com/tecki/cpython/blob/pep487b/Lib/test/test_subclassinit.py</a>),<br>
>>> the test runs on older Pythons.<br>
>>><br>
>>> But I see that my idea to formulate things here in Python was a bad<br>
>>> idea, I will put the explanation first and turn the code into<br>
>>> pseudo-code.<br>
>>><br>
>>>>>         def __init__(self, name, bases, ns, **kwargs):<br>
>>>>>             super().__init__(name, bases, ns)<br>
>>>><br>
>>>> What does this definition of __init__ add?<br>
>>><br>
>>> It removes the keyword arguments. I describe that in prose a bit down.<br>
>>><br>
>>>>>     class object:<br>
>>>>>         @classmethod<br>
>>>>>         def __init_subclass__(cls):<br>
>>>>>             pass<br>
>>>>><br>
>>>>>     class object(object, metaclass=type):<br>
>>>>>         pass<br>
>>>><br>
>>>> Eek! Too many things named object.<br>
>>><br>
>>> Well, I had to do that to make the tests run... I'll take that out.<br>
>>><br>
>>>>> In the new code, it is not ``__init__`` that complains about keyword arguments,<br>
>>>>> but ``__init_subclass__``, whose default implementation takes no arguments. In<br>
>>>>> a classical inheritance scheme using the method resolution order, each<br>
>>>>> ``__init_subclass__`` may take out it's keyword arguments until none are left,<br>
>>>>> which is checked by the default implementation of ``__init_subclass__``.<br>
>>>><br>
>>>> I called this out previously, and I am still a bit uncomfortable with<br>
>>>> the backwards incompatibility here. But I believe what you describe<br>
>>>> here is the compromise proposed by Nick, and if that's the case I have<br>
>>>> peace with it.<br>
>>><br>
>>> No, this is not Nick's compromise, this is my original. Nick just sent<br>
>>> another mail to this list where he goes a bit more into the details,<br>
>>> I'll respond to that about this topic.<br>
>>><br>
>>> Greetings<br>
>>><br>
>>> Martin<br>
>>><br>
>>> P.S.: I just realized that my changes to the PEP were accepted by<br>
>>> someone else than Guido. I am a bit surprised about that, but I guess<br>
>>> this is how it works?<br>
>>> _______________________________________________<br>
>>> Python-Dev mailing list<br>
>>> <a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
>>> <a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
>>> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> --Guido van Rossum (<a href="http://python.org/~guido" rel="noreferrer" target="_blank">python.org/~guido</a>)<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
<br>
<br>
<br>
--<br>
--Guido van Rossum (<a href="http://python.org/~guido" rel="noreferrer" target="_blank">python.org/~guido</a>)<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/mistersheik%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/mistersheik%40gmail.com</a><br>
</blockquote></div></div></div>