[Python-Dev] How to suppress instance __dict__?

Guido van Rossum guido@python.org
Sun, 23 Mar 2003 16:15:15 -0500


> It's almost too bad that the distinction between __new__ and __init__
> is there -- as we find we need to legitimize the use of __new__ with
> things like __getnewargs__ it be comes a little less clear which one
> should be used, and when.  TIMTOWDI and all that.

__new__ creates a new, initialized object.  __init__ sets some values
in an exsting object.  __init__ is a regular method and can be called
to reinitialize an existing object (not that I recommend this, but the
mechanism doesn't forbid it).  It follows that immutable objects must
be initialized using __new__, since by the time __init__ is called the
object already exists and is immutable.

> In the absence of clear guidelines I'm tempted to suggest that C++ got
> this part right.

Of course you would.

I tend to think that Python's analogon to C++ constructors is __new__,
and that __init__ is a different mechanism (although it can often be
used where you would use a constructor in C++).

> Occasionally we get people who think they want to call overridden
> virtual functions from constructors (I presume the analogous thing
> could be done safely from __init__ but not from __new__)

Whether or not that can be done safely from __init__ depends on the
subclass __init__; it's easy enough to construct examples that don't
work.  But yes, for __new__ the situation is more analogous to C++,
except that AFAIK in C++ when you try that you get the base class
virtual function, while in Python you get the overridden method --
which finds an instance that is incompletely initialized.

> but that's pretty rare.  I'm interested in gaining insight into the
> Pythonic thinking behind __new__/__init__; I'm sure I don't have the
> complete picture.

__new__ was introduced to allow initializing immutable objects. It
really applies more to types implemented in C than types implemented
in Python.  But it is needed so that a Python subclass of an immutable
C base classs can pass arguments of its choice to the C base class's
constructor.

> Nice. Too bad about 2.2.

Maybe the new pickling could be backported, but I fear that it depends
on some other 2.3 feature that's harder to backport, so I haven't
looked into this.

--Guido van Rossum (home page: http://www.python.org/~guido/)