__init__ explanation please

[Steven D'Aprano]

On Tue, 15 Jan 2008 14:02:43 -0800, Lie wrote:

> I've been in this Python mailing list for a few days, and I've noticed
> several things here: There are too many fundamentalist!
> 
> Don't play stupid and all, don't be a fundamentalist. It might be true
> that __init__ isn't a constructor and __new__ might be the constructor

It is true.


> (some people even claimed __new__ is also not a constructor).

They did? I must have missed them.


> From the base definition of a constructor: constructor is the creator of
> an object. In this case, __new__ is technically the constructor while
> __init__ is an initializer.

Yes, that is correct, although I too have been known to use "constructor" 
to *informally* refer to __init__. It's a bad habit, and while 
technically wrong, not always unforgivably wrong.


> However, it is also to be noted that __init__ is what makes an object
> meaningful, and that makes it a constructor in a sense (while still
> technically a constructor). Without initialization, an object is
> meaningless, even if the definition of the initializer is to leave it as
> it is.

Nope, not at all. The following class does not call the initializer:

class MyClass(object):
    class __metaclass__(type):
        def __call__(cls, *args, **kwargs):
            obj = cls.__new__(cls)
            print "There is no __init__."
            return obj
    def __new__(cls, *args, **kwargs):
        print "This is the constructor, see me construct an instance!"
        return object.__new__(cls)
    def __init__(self, *args, **kwargs):
        raise Exception("die die die!!!")


Now use it:

>>> c = MyClass()
This is the constructor, see me construct an instance!
There is no __init__.

And call the initializer by hand:

>>> c.__init__()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 7, in __init__
Exception: die die die!!!


Here's a class with no constructor (or rather, a constructor that the 
user *can't get to*):

class OldClass:
    def __new__(cls, *args, **kwargs):  # this is not called
        raise Exception("die die die!!!")
    def __init__(self, *args, **kwargs):
        print "This is the initializer, see me initialize " \
        "the already-constructed instance 'self'!"


>>> c = OldClass()
This is the initializer, see me initialize the already-constructed 
instance 'self'!


For various reasons, Python splits the process of constructing and 
initializing instances into two stages. What other languages do is 
irrelevant. Perhaps Java and C++ don't need to distinguish between 
"constructor" and "initializer", but Python does.



> Python creates object by doing something like this: a = anObject(arg1,
> arg2, arg3)

That's what the programmer does. Under the hood, Python does something 
different.


> These arguments is then passed to __new__ and __init__ for their
> arguments in its sake of creating and initializing the object. Then
> anObject() returns an instance of anObject.

Assuming the standard metaclass.


> From an outsider's point of view, there is no difference between __new__
> and __init__ since they're "implementation details" 

No, they most certainly are not implementation details. ANY 
implementation of Python MUST use __new__ and __init__ or else it is not 
Python, it is a different language. The nature of how Python creates 
instances is part of the language specification, not the implementation.


> (in other languages,
> these are private functions[1] that is invisible to outsiders, Python
> doesn't like privacy but the semantic of being implementation detail
> still exist). For an outsider, there is absolutely no need to know that
> __new__ and __init__ exists, they just need to know anObject()'s
> arguments, which is the public view of the constructor and
> initializer[2].

I don't understand your argument. If you are saying that people who don't 
care about the details of Python instance creation don't care about the 
details of Python instance creation, then you're right, but it's a rather 
pointless observation. Yes, people who don't care don't care.

But people who want to:

(1) Program successfully in Python;

(2) Compare how Python works to other computer languages;

(3) Do metaclass programming; or

(4) Find out how Python creates instances

will care about the details. Anybody asking for an explanation of 
__init__ (like this thread!) is asking about the details. Why on earth do 
you think it is a bad thing to answer the question accurately?


[snip]
> If you can't be convinced with this argument, then I'd give you another
> that's a bit more Pythonic:
> DUCK TYPING: If it looks like a duck, walks like a duck, and quacks like
> a duck, it is a duck!
> 
> From the class programmer's point of view, __init__ acts like an object
> constructor in other languages, there is no significant difference
> between __init__ and constructor in other languages. 

Fortunately, Python isn't those other languages. We're not discussing how 
Java creates instances, or C++, or VisualBasic. We're discussing Python, 
so any answer given that starts off "Well, in Java it works like this..." 
is almost certainly going to be useless to the Python programmer asking 
about Python.

[snip]
> In this sense, VB's New, C ++
> constructor, and C# constructor is equal to Python's __init__, thus the
> Duck Typing spirit applies here.

It isn't enough to quack like a duck. It also needs to walk like a duck 
and swim like a duck too.



-- 
Steven