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