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 <gu...@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.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
