Shouldn't __init__ return self instead of None? (Was: Re: [Tutor] Why error if method __init__ does not return none)

Mike C. Fletcher mcfletch at
Sat Mar 22 23:20:06 CET 2003

>This raises an interesting question. Shouldn't it say: __init__ should
>return self...? Because _that_ is what it really does...
type.__init__ is an *initialiser* that may be called after object 
construction. It's _not_ an object *constructor*, and it doesn't return 
"self" for that reason.  You can create objects without calling their 
initialisers (particularly when dealing with storage systems such as 
pickle).  Having the seperate __init__ makes that possible.

Most Python classes just use __init__, since it's doing what most people 
want to do with their classes on instantiation (i.e. initialise them 
using side-effects such as data-storage, seting up database connections, 
or what have you).  That makes it seem more like __init__ is a 
constructor, such as you see commonly in other languages, but it's 
really not one.

type.__new__ is the constructor which operates the way I'm imagining 
you're imagining __init__ should.  That is, it takes a set of arguments, 
the first of which is the class to be instantiated, and returns a new 
instance of the class.

 >>> class MyClass( object ):
...     def __new__( clsObject, *arguments, **named ):
...         print '__new__'
...         base = super(MyClass,clsObject).__new__(clsObject)
...         print '__new__ finished'
...         return base # here's what MyClass.__call__ will eventually 
...     def __init__( self, someValue = 4 ):
...         print '__init__'
...         self.someValue = someValue # a side-effect which alters the 
 >>> a = MyClass(someValue=5)
__new__ finished
 >>> a.someValue

You _could_ use __new__ to do all of the initialisation, but I certainly 
wouldn't recommend it, as then machinery which relies on being able to 
perform two-stage initialisation (such as pickle) may become unhappy 
with you :) .

BTW: The class object's __call__ method is doing the calls to __new__, 
then to __init__, then returning the resulting instance object.  That 
is, the thing which ultimately "returns self" is the class' __call__ 
method, not __init__.  Using meta-classes you can rewrite __call__ to do 
the initialisation and return the new objects.  Again, I wouldn't 
recommend that :) .


Gerrit Holl wrote:

>[FUP: python-list at]
>Bob Gailer schreef op zaterdag 22 maart om 18:05:29 +0000:
>>What is "returned" here is an instance of the class, not what is returned 
>>by the __init__ method. I guess that "TypeError: __init__() should return 
>>None" is a way of telling you not to return something else with the 
>>expectation that it will be available.
>This raises an interesting question. Shouldn't it say: __init__ should
>return self...? Because _that_ is what it really does...
>Of course, changing this would break code, but moving towards this might
>be a good idea...?
  Mike C. Fletcher
  Designer, VR Plumber, Coder

More information about the Python-list mailing list