Please notice that I'm talking about concrete, real issues, not just a "super is bad!" rant.
Then why is the title "Python's Super Considered Harmful" ??? Here's my final offer. Change the title to something like "Multiple Inheritance Pitfalls in Python" and nobody will get hurt.
They are not inherent in cooperative multiple inheritance, but occur mostly because of its late addition to python,
Would you rather not have seen it (== cooperative inheritance) added at all?
and the cumbersome way in which you have to invoke super.
Given Python's dynamic nature I couldn't think of a way to make it less cumbersome. I see you tried (see below) and couldn't either. At this point I tend to say "put up or shut up."
I wrote up the page as part of an investigation into converting Twisted to use super. I thought it would be a good idea to do the conversion, but others told me it would be a bad idea for backwards compatibility reasons. I did not believe, at first, and conducted experiments. In the end, I concluded that it is not possible, because of the issues with mixing the new and old paradigm.
So it has nothing to do with the new paradigm, just with backwards compatibility. I appreciate those issues (more than you'll ever know) but I don't see why you should try to discourage others from using the new paradigm, which is what your article appears to do.
Leaving behind the backwards compatibility issues...
In order to make super really nice, it should be easier to use right. Again, the two major issues that cause problems are: 1) having to declare every method with *args, **kwargs, and having to pass those and all the arguments you take explicitly to super,
That's only an issue with __init__ or with code written without cooperative MI in mind. When using cooperative MI, you shouldn't redefine method signatures, and all is well. and 2) that
traditionally __init__ is called with positional arguments.
Cooperative MI doesn't have a really good solution for __init__. Defining and calling __init__ only with keyword arguments is a good solution. But griping about "traditionally" is a backwards compatibility issue, which you said you were leaving behind.
To fix #1, it would be really nice if you could write code something like the following snippet. Notice especially here that the 'bar' argument gets passed through C.__init__ and A.__init__, into D.__init__, without the previous two having to do anything about it. However, if you ask me to detail how this could *possibly* *ever* work in python, I have no idea. Probably the answer is that it can't.
Exactly. What is your next_method statement supposed to do? No need to reply except when you've changed the article. I'm tired of the allegations. -- --Guido van Rossum (home page: http://www.python.org/~guido/)