[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