On 17 April 2011 02:48, Steven D'Aprano
<steve@pearwood.info> wrote:
Michael Foord wrote:
On 15/04/2011 02:23, Steven D'Aprano wrote:
[...]
If we treat django's failure to use super as a bug, you want the Python language to work-around that bug so that:
What you say (that this particular circumstance could be treated as a bug in django) is true, however consider the "recently" introduced problem caused by object.__init__ not taking arguments. This makes it impossible to use super correctly in various circumstances.
[...]
It is impossible to inherit from both C and A and have all parent __init__ methods called correctly. Changing the semantics of super as described would fix this problem.
So you say. I don't have an an opinion on whether or not you are technically correct, but adding DWIM black-magic to super scares me.
Well, super is already pretty "magic" and what I'm suggesting is no more magic than currently exists. I'm suggesting (but it won't happen - no-one else is in favour :-) *extending* the existing algorithm in a predictable and understandable way. The main advantage is that it allows methods to express "don't call my parent class methods but don't halt the chain of calling", which is currently not possible (so in that context I don't really know what you mean by "DWIM black-magic"). I'm *not* suggesting full auto calling.
All the best,
Michael
It scares me even if it were guaranteed to *only* apply to __init__, but if it applied to arbitrary methods, it frankly terrifies me.
If it were limited to only apply to __init__, there would be a constant stream of requests that we loosen the restriction and "make super just work" for all methods, despite the dangers of DWIM code.