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/archive%40mail-archive.com
