[Python-Dev] Breaking calls to object.__init__/__new__

[Aahz]

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