[Python-Dev] How to suppress instance __dict__?

[David Abrahams]

Guido van Rossum <guido@python.org> writes:

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

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.

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

Oh, c'mon.  C++ is ugly, both brittle *and* inflexible, expensive,
painful, etc.  There must be at least _one_ well-designed thing about
it.  Maybe this is it!

> I tend to think that Python's analogon to C++ constructors is
> __new__,

Yup.

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

Either one seems equally likely to be what you don't want.

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

Are people who don't want to upgrade really that much more willing if
it doesn't involve a minor revision number?  I figure that if I
supported 2.2 once, I'd have to be very circumspect about doing
something which required an upgrade to 2.2.x.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com