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