A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2007-March/072255.html below:

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

[Python-Dev] Breaking calls to object.__init__/__new__ [Python-Dev] Breaking calls to object.__init__/__new__Guido van Rossum guido at python.org
Thu Mar 22 05:36:52 CET 2007
On 3/21/07, Aahz <aahz at pythoncraft.com> wrote:
> 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.

For what?

> 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.

A trivial fix to get the behavior you want is to introduce a new class
Object that all your company's classes derive from which has an
__init__ that ignores its arguments and does nothing.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4