[Python-Dev] Breaking calls to object.__init__/__new__
Aahz
aahz at pythoncraft.com
Thu Mar 22 05:12:22 CET 2007
On Wed, Mar 21, 2007, Guido van Rossum wrote:
> On 3/21/07, Jean-Paul Calderone <exarkun at divmod.com> wrote:
>>
>> I think I understand the desire to pull keyword arguments out at each
>> step of the upcalling process, but I don't see how it can work, since
>> "up" calling isn't always what's going on - given a diamond, there's
>> arbitrary side-calling, so for cooperation to work every method has to
>> pass on every argument, so object.__init__ has to take arbitrary args,
>> since no one knows when their "up" call will actually hit object.
>>
>> Since without diamonds, naive "by-name" upcalling works, I assume that
>> super() is actually intended to be used with diamonds, so this seems
>> relevant.
>
> There are different philosophies about the correct style for
> cooperative super calls.
Maybe so, but this would massively break my company's application, if we
were actually using new-style classes and the built-in super(). We have
a web application that commonly passes all form fields down as **kwargs;
the application uses lots of mixin classes with identically-named
methods. We have a home-brew super() that crawls the stack.
Call me a strong -1 on this now that JP has explained what it does. I
can't believe we're the only people doing this. I guess it doesn't
matter as much for 3.0 because we're probably going to have to do a
massive rewrite for that, anyway. (This codebase started in 1.4 and
we're still running against 2.2.) But my take is that this is still an
ugly fix.
--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/
"Typing is cheap. Thinking is expensive." --Roy Smith
More information about the Python-Dev
mailing list