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

Mon Jul 18 19:26:29 EDT 2016

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 <guido at 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.teichmann at 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 <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)
> > _______________________________________________
> > 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)
> _______________________________________________
> 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/mistersheik%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160718/53bb8c0b/attachment-0001.html>