int.__init__ incompatible in Python 3.3
steve+comp.lang.python at pearwood.info
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 dominolaser.com> 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