On Wed, Mar 21, 2007, Guido van Rossum wrote: > On 3/21/07, Jean-Paul Calderone <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Typing is cheap. Thinking is expensive." --Roy Smith _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
