Re: [Python-Dev] PEP487: Simpler customization of class creation
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 : > 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 > 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 >> [email protected] >> 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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP487: Simpler customization of class creation
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 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 : >> 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 >> 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 >>> [email protected] >>> 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) > _
Re: [Python-Dev] __qualname__ exposed as a local variable: standard?
Hi, so I did quite some research on this topic. And what I found out is that __qualname__ needs to exist in the namespace. Not necessarily because it should be used, but because it may be modified. The story goes as follows: the compiler sets the __qualname__ at the beginning of the class body. Within the class body, it may be modified as needed. Then type.__new__ takes it and uses it. Now one could think that instead of setting the __qualname__ at the beginning of the class body, we could do so at the end as to not clutter the namespace, and only if the __qualname__ has been set in the class body we would use the user-supplied version. But this is forgetting __prepare__: unfortunately, we have no good way to find out whether something has been set in a class body, because we have no guarantee that the object returned by __prepare__ doesn't do something weird, as autogenerating values for all requested keys. > To Martin: it would be easier for people (even myself, who implemented > this super() hack eons ago) to review your patch if you were able to > explain the current and proposed behavior more precisely. I tried to give some context on my issue (http://bugs.python.org/issue23722). Hope that helps. Greetings Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __qualname__ exposed as a local variable: standard?
So, for __qualname__, should we just update the docs to make this the law? If that's your recommendation, I'm fine with it, and you can submit a doc patch. On Sun, Jul 17, 2016 at 10:01 AM, Martin Teichmann wrote: > Hi, > > so I did quite some research on this topic. And what I found out is > that __qualname__ needs to exist in the namespace. Not necessarily > because it should be used, but because it may be modified. > > The story goes as follows: the compiler sets the __qualname__ at the > beginning of the class body. Within the class body, it may be modified > as needed. Then type.__new__ takes it and uses it. > > Now one could think that instead of setting the __qualname__ at the > beginning of the class body, we could do so at the end as to not > clutter the namespace, and only if the __qualname__ has been set in > the class body we would use the user-supplied version. But this is > forgetting __prepare__: unfortunately, we have no good way to find out > whether something has been set in a class body, because we have no > guarantee that the object returned by __prepare__ doesn't do something > weird, as autogenerating values for all requested keys. > >> To Martin: it would be easier for people (even myself, who implemented >> this super() hack eons ago) to review your patch if you were able to >> explain the current and proposed behavior more precisely. > > I tried to give some context on my issue > (http://bugs.python.org/issue23722). Hope that helps. > > Greetings > > Martin > ___ > Python-Dev mailing list > [email protected] > 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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP487: Simpler customization of class creation
On 07/17/2016 09:57 AM, Guido van Rossum wrote: This PEP is now accepted for inclusion in Python 3.6. Martin, congratulations! Congratulations, Martin! I'm looking forward to this feature. :) -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP487: Simpler customization of class creation
> This PEP is now accepted for inclusion in Python 3.6. Martin, > congratulations! Thank you very much! What a great news! Greetings Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
