Nick Coghlan added the comment:
I started reviewing Martin's patch, and I initially thought I had found a
problem with the way __init_subclass__ is currently defined. It turned out I
was wrong about it actually being broken, but I *do* now think it's inherently
confusing, and we may be able to do something different that's more obviously
correct (or at least easier to document - it was proposing revisions to the
documentation that got me thinking along this path).
Specifically, I was thinking using super() in either the zero argument form or
the explicit form could create an infinite loop due to the way we're currently
proposing to interact with the MRO. Consider:
class BaseClass:
@classmethod
def __init_subclass__(cls):
super(cls, BaseClass).__init_subclass__()
class SubClass(BaseClass):
pass
If the initial call made by type.__new__() is effectively
"SubClass.mro()[1].__init_subclass__()", then the super() call is going to call
BaseClass.__init_subclass__ again.
However, it turned out I was wrong, as that's not what happens: the call made
by the type machinery is instead "super(SubClass, SubClass).__init_subclass__",
which gets it to the right place in the MRO and causes further super() calls to
do the right thing.
However, the "more obviously correct" signature that occurred to me was to do
this instead:
class BaseClass:
@classmethod
def __init_subclass__(cls, subcls):
super(cls, BaseClass).__init_subclass__(subcls)
class SubClass(BaseClass):
pass
Then the invocation from type.__new__ could be defined more simply as:
SubClass.mro()[1].__init_subclass__(SubClass)
In all cases then (regardless of where you were in the MRO), "cls" would refer
to "the class first in the MRO after the class being defined" and "subcls"
would refer to "the class currently being defined".
If you consider the plugin example in the PEP, with the revised signature, it
would look like:
class PluginBase:
subclasses = []
def __init_subclass__(cls, subcls, **kwargs):
super().__init_subclass__(**kwargs)
cls.subclasses.append(subcls)
And *even if the subclass being defined shadowed the "subclasses" attribute*,
this initialisation would still work. (You can still get yourself in trouble if
a subclass somewhere else in the MRO shadows the attribute, but that's life in
complex type hierarchies)
In the version in the PEP, the fact that "cls" is actually a subclass, and
we're relying on the MRO to find "subclasses" is a really subtle implementation
detail, while having two parameters makes it clear that "the class defining
__init_subclass__" is distinct from the "new subclass being defined".
----------
nosy: +gvanrossum
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27366>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
