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.teichm...@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@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) _______________________________________________ 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
