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