On Tue, Jul 16, 2019 at 3:32 PM Ian Kelly <ian.g.ke...@gmail.com> wrote: > > On Sun, Jul 14, 2019 at 7:14 PM Chris Angelico <ros...@gmail.com> wrote: > > > > On Mon, Jul 15, 2019 at 10:51 AM Paulo da Silva > > <p_s_d_a_s_i_l_v_a...@netcabo.pt> wrote: > > > > > > Às 15:30 de 12/07/19, Thomas Jollans escreveu: > > > > On 12/07/2019 16.12, Paulo da Silva wrote: > > > >> Hi all! > > > >> > > > >> Is there any difference between using the base class name or super to > > > >> call __init__ from base class? > > > > > > > > There is, when multiple inheritance is involved. super() can call > > > > different 'branches' of the inheritance tree if necessary. > > > > ... > > > > > > Thank you Jollans. I forgot multiple inheritance. I never needed it in > > > python, so far. > > > > > > > Something to consider is that super() becomes useful even if someone > > else uses MI involving your class. Using super() ensures that your > > class will play nicely in someone else's hierarchy, not just your own. > > Just using super() is not enough. You need to take steps if you want to > ensure that you class plays nicely with MI. For example, consider the > following: > > class C1: > def __init__(self, name): > self._name = name > > class C2(C1): > def __init__(self, name, value): > super().__init__(name) > self._value = value > > This usage of super is just fine for the single-inheritance shown here. But > there are two reasons why this cannot be neatly pulled into an MI > hierarchy. Can you spot both of them?
Well, obviously it's violating LSP by changing the signature of __init__, which means that you have to be aware of its position in the hierarchy. If you want things to move around smoothly, you HAVE to maintain a constant signature (which might mean using *args and/or **kwargs cooperatively). I'm not sure what the second issue is, though. It's kinda hard to imagine a real-world situation where this would come up (some things have names but not values, others have values... what third class could you bring in that would make sense here?), so I'm unsure whether you're pointing to "self._value" as a problem. Personally, I'd use "self.value = value" and not try to pretend that it's private. (Not a fan of "self.__value" because subclasses can't use it usefully AT ALL, so unless you're absolutely perfectly maintaining a consistent public signature - which you're not, see the first point - there's no way you can do anything good with it.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
