Guido van Rossum <guido@python.org> writes:
[Guido]
__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.
[David again]
Shouldn't most objects be initialized by __new__, really? IME it's dangerous to have uninitialized objects floating about, especially in the presence of exceptions.
Normally, there are no external references to an object until after __init__ returns
Good point; that's a feature you don't get unless you build two-phase initialization into the core language. Two-phase initialization is more dangerous in C++ because it's not a core language feature.
so you should be safe unless __init__ saves a reference to self somewhere. It does mean that __del__ can be surprised by an uninitialized object, and that's a known pitfall. And an exception in the middle of __new__ has the same problem.
C++ deals with that by only destroying the fully-initialized bases and subobjects when an exception is thrown during construction. That's hard to do in the presence of two-phase initialization, though. It may be less of a problem for Python because __del__ is much less commonly needed than nontrivial destructors are in C++.
So I don't think __new__ is preferred over __init__, unless you need a feature that only __new__ offers (like initializing an immutable base class or returning an existing object or an object of a different class).
In other words, TIMTOWTDI? <0.3 wink> -- Dave Abrahams Boost Consulting www.boost-consulting.com