> I'd say NOT wanting to call an __init__ method of a superclass is a
> rather uncommon occurence. It's generally a huge error. So I think
> it's worth not accomodating that.
I will give you an example then where I am absolutely fine with calling
super().__init__ in all classes and describe why I am not really satisfied with
the current status. (It is from my email from yesterday 17:19 GMT):
> What bugs me is that in my example from yesterday (
> class Aardvark:
> def __init__(self, quantity, **kwargs):
> print("There is some quantity:", quantity)
> # I actually don’t care about **kwargs and just hand them on
> super().__init__(**kwargs)
>
> class Clever:
> def __init__(self, cleverness=1):
> print("You are %d clever“ % cleverness)
>
> class Ethel(Aardvark, Clever):
> """Ethel is a very clever Aardvark"""
> def __init__(self):
> super().__init__(quantity="some spam", cleverness=1000)
> ) if you want to instantiate an Aardvark directly there is NO WAY EVER that
> you could give him ANY kwargs. So why should the __init__ indicate something
> else? Well, just to make the MRO work. All I want is to make it as obvious as
> possible that an Aardvark only takes `quantity` as input, but is fully
> "cooperative" with other classes if it is in the middle of the MRO (by which
> I mean that it will automatically call the __init__ and hand on any kwargs it
> didn’t expect to a class from a different branch of the class hierarchy).
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
