Yes, I'm very excited about this! Will this mean no more metaclass conflicts if using @abstractmethod?
On Sun, Jul 17, 2016 at 12:59 PM Guido van Rossum <gu...@python.org> wrote: > This PEP is now accepted for inclusion in Python 3.6. Martin, > congratulations! Someone (not me) needs to review and commit your > changes, before September 12, when the 3.6 feature freeze goes into > effect (see https://www.python.org/dev/peps/pep-0494/#schedule). > > On Sun, Jul 17, 2016 at 4:32 AM, Martin Teichmann > <lkb.teichm...@gmail.com> wrote: > > 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/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/mistersheik%40gmail.com >
_______________________________________________ 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
