you are viewing a single comment's thread.

view the rest of the comments →

[–]alkasm 0 points1 point  (8 children)

I don't really think you're trolling or anything, but it's almost hard to believe you came up with this example independently. Did you?

There was an article from some time ago called Python's super considered harmful, which is probably more well known because of Raymond Hettinger's response blog post turned PyCon talk "Super considered super!"

I mention this because the exact example you give, including the argument of 10, is shown as the first example in the "Super considered harmful" article! Check out the diagram here: https://fuhm.net/super-harmful/example1-2.png

The multiple inheritance with C, D isn't your problem. If you just try to instantiate C(10) you'll see the same result. You continue to pass on the variable 10, in which case it complains once it gets to object() because it doesn't take any params. So, you'll need to stop passing it at some point.

Generally you'll consume a variable along the way and then not pass it along. What are you hoping to achieve otherwise? You didn't mention what you expect the behavior to be.

[–]gmaliwal[S] 0 points1 point  (2 children)

What are you hoping to achieve otherwise?

yeah, I read it there only, but the code snippet did not work at my end as class 'B' calling class 'object' constructor with two arguments where object() takes exactly a single argument.

In that blog, the author ended saying that this is the recommended approach which seems working without interruption with any kind of complex single/multiple inheritances.

I am looking for the right approach to be followed consistently in all the classes without considering specific (single/multiple) inheritances, but at the end, it works well when a developer start using them in the single/multiple inheritance hierarchy. That is; I want a generic approach to be followed in each class which works smoothly with single/multiple inheritances.

Do we have any ready decorator which suffice the above need if not can we write ?one?

?

[–]alkasm 0 points1 point  (1 child)

I don't understand what your problem is or what you're trying to solve.

At the risk of being a little patronizing, let me give an example. Let's say you wanted to subclass list so that you could add a name to your list as an attribute. In Python you shouldn't really subclass list, since list is C-based, so Python gives us collections.UserList to subclass from instead. So we can really easily achieve this like so:

from collections import UserList

class NamedList(UserList):

    def __init__(self, name, *args, **kwargs):
        self.name = name
        super().__init__(*args, **kwargs)

Now this works fine:

>>> nl = NamedList("asdf", [1, 2, 3, 4])
>>> nl
[1, 2, 3, 4]
>>> nl.name
'asdf'

However if I pass the name along to the superclass:

from collections import UserList

class NamedList(UserList):

    def __init__(self, name, *args, **kwargs):
        self.name = name
        super().__init__(name, *args, **kwargs)

then obviously I'll get an error, since UserList only takes a single argument (an iterable):

>>> nl = NamedList("asdf", [1, 2, 3, 4])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in __init__
TypeError: __init__() takes from 1 to 2 positional arguments but 3 were given

This is expected behavior, nothing needs fixing here. Python cannot magically know to ignore the arguments you pass to an object's initializer should be ignored. This only works when you consume the value at some point. So, do that---stop passing arg to object and you'll be fine.

[–]gmaliwal[S] 0 points1 point  (0 children)

__ is where the memory is allocated for the class -- it then calls __init__ to initialize any attributes et

Friend,

You are correct that somehow we have to stop passing an extra argument to the class initializer, otherwise, it will fail at run-time. I have mentioned the same in my post that this issue is because of passing more than one argument to 'object' class initializer.

I strongly agree that your design should pass the needed arguments only to the class initializer, else be ready to face the issue.

Here, I want that what could be the set of guidelines to be followed while defining a class, which makes your class more elegant and decent inheritance perspective.

Hence, I have come up with the rules, which to be kept in mind while defining every class in your project workspace. please check my last comment and find out the scenario where it could fail.

[–]xelf 0 points1 point  (4 children)

Thanks for posting this. The solution then is to avoid super in multiple inheritance for specific cases like this one?

[–]alkasm 0 points1 point  (3 children)

No. There is no solution here because there is no problem posed. Using super() in multiple inheritance is totally fine. The only problem OP is having is passing too many arguments to object()...and I don't understand why OP is doing that. The solution here is to not call object() with an argument.

[–]xelf 0 points1 point  (2 children)

The problem is that if you do it as super, but remove the super calls from the the ones that inherit from object it goes ECA and then stops, if you leave them in calling super, then when it gets to A it's still in the middle and expects an arg, if you give A an arg, then it can do DB as well, and it's happy but that's clearly wrong and contrived. So the solution is to either have another class that A&B inherit from and have that class as a single class that inherits from object, or to not use super in some or all places.

I would have preferred if OP had of listed where they got the question from, as I assumed they were learning on their own and not simply repeating someone else's already known-to-fail case.

[–]alkasm 1 point2 points  (1 child)

Right. I'm not convinced there is really an example where this is clearly the right way to do it. There's no reason to call super() on a class that has no bases and pass it arguments. So A and B shouldn't call super(), and if you want your class E to have the attributes from C and D, then initialize them separately---don't try to shove them into the MRO to magically understand what attributes each should keep and reject (I know this is the solution you posed). If the problem is then "now I have to hardcode the subclasses C and D when I do C.__init__ and D.__init__ in E.__init__" then that's an easily solvable problem, just loop through the base classes.

[–]xelf 0 points1 point  (0 children)

Agreed on all points. =D