int.__init__ incompatible in Python 3.3

Steven D'Aprano steve+comp.lang.python at
Fri Nov 9 12:37:45 CET 2012

On Fri, 09 Nov 2012 08:56:22 +0100, Ulrich Eckhardt wrote:

> Am 08.11.2012 21:29, schrieb Terry Reedy:
>> On Thu, Nov 8, 2012 at 8:55 AM, Ulrich Eckhardt
>> <ulrich.eckhardt at> wrote:
>>>> On 3.3, it gives me a "TypeError: object.__init__() takes no
>>>> parameters". To some extent, this makes sense to me, because the int
>>>> subobject is not initialized in __init__ but in __new__. As a
>>>> workaround, I can simple drop the parameter from the call.
>> Just drop the do-nothing call.
> Wait: Which call exactly?
> Do you suggest that I shouldn't override __init__? The problem is that I
> need to attach additional info to the int and that I just pass this to
> the class on contstruction.

No, of course not. If you need to override __init__, you need to override 

> Or, do you suggest I don't call super().__init__()? That would seem
> unclean to me.

On the contrary: calling super().__init__ when the superclass does 
something you don't want (i.e. raises an exception) is unclean.

Since the superclass __init__ does nothing, you don't need to call it. 
Only inherit behaviour that you actually *want*.

In Python 3.3:

py> class X(int):
...     def __init__(self, *args):
...         super().__init__(*args)  # does nothing, call it anyway
py> x = X(22)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in __init__
TypeError: object.__init__() takes no parameters

It is apparently an oversight, or a bug, that it ever worked in older 

> Note that even though I derive from an immutable class, the resulting
> class is not formally immutable. Maybe exactly that is the thing that
> the developers did not want me to do?

Nope, that's irrelevant. Attaching attributes to an otherwise immutable 
object is fine.


More information about the Python-list mailing list