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.eckha...@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 __init__. > 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 versions. > 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list