[Python-Dev] How to suppress instance __dict__?
Sun, 23 Mar 2003 16:53:09 -0500
Guido van Rossum <email@example.com> 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
> 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
>> 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.