__init__ is the initialiser

[Ned Batchelder]

On 1/31/14 2:33 PM, Mark Lawrence wrote:
>  From http://docs.python.org/3/reference/datamodel.html#object.__init__
> which states:-
>
> "
> Called when the instance is created. The arguments are those passed to
> the class constructor expression. If a base class has an __init__()
> method, the derived class’s __init__() method, if any, must explicitly
> call it to ensure proper initialization of the base class part of the
> instance; for example: BaseClass.__init__(self, [args...]). As a special
> constraint on constructors, no value may be returned; doing so will
> cause a TypeError to be raised at runtime.
> "
>
> Should the wording of the above be changed to clearly reflect that we
> have an initialiser here and that __new__ is the constructor?
>

I'm torn about that.  The fact is, that for 95% of the reasons you want 
to say "constructor", the thing you're describing is __init__.  Most 
classes have __init__, only very very few have __new__.

The sense that __new__ is the constructor is the one borrowed from C++ 
and Java: you don't have an instance of your type until the constructor 
has returned.  This is why __init__ is not a constructor: the self 
passed into __init__ is already an object of your class.

But that distinction isn't useful in most programs.  The thing most 
people mean by "constructor" is "the method that gets invoked right at 
the beginning of the object's lifetime, where you can add code to 
initialize it properly."  That describes __init__.

Insisting that __init__ is not a constructor makes about as much sense 
as insisting that "Python has no variables" just because they work 
differently than in C.  Python has variables, and it has constructors. 
We don't have to be tied to C++ semantics of the word "constructor" any 
more than we have to tied to its semantics of the word "variable" or "for".

Why can't we call __init__ the constructor and __new__ the allocator?

-- 
Ned Batchelder, http://nedbatchelder.com