[issue1683368] object.__init__ shouldn't allow args/kwds

[Jason R. Coombs]

Jason R. Coombs added the comment:

Maybe I should have focused on a more trivial example to demonstrate the place where my expectation was violated. The use of a real-world example is distracting from my intended point. Consider instead this abstract example:

class SomeClass(SomeParentClass):
    def __new__(cls, *args, **kwargs):
        return super(SomeClass, cls).__new__(cls, *args, **kwargs)

    def __init__(self, *args, **kwargs):
        super(SomeClass, self).__init__(*args, **kwargs)

Ignoring for a moment the incongruity of the invocation of __new__ with 'cls' due to __new__ being a staticmethod, the naive programmer expects the above SomeClass to work exactly like SomeParentClass because both overrides are implemented as a trivial pass-through.

And indeed that technique will work just fine if the parent class implements both __init__ and __new__, but if the parent class (or one of its parents) does not implement either of those methods, the technique will fail, because the fall through to 'object' class.

I believe this incongruity stems from the fact that __new__ and __init__ are special-cased not to be called if they aren't implemented on the class.

Therefore, to write SomeClass without knowledge of the SomeParentClass implementation, one could write this instead:

class SomeClass(SomeParentClass):
    def __new__(cls, *args, **kwargs):
        super_new = super(SomeClass, cls).__new__
        if super_new is object.__new__:
            return super_new(cls)
        return super_new(cls, *args, **kwargs)

    def __init__(self, *args, **kwargs):
        super_init = super(SomeClass, self).__init__
        if super_init.__objclass__ is object:
            return
        super_init(*args, **kwargs)

Now that implementation is somewhat ugly and perhaps a bit brittle (particularly around use of __objclass__). Ignoring that for now, it does have the property that regardless of the class from which it derives, it will work, including:

SomeParentClass = datetime.datetime # implements only __new__
SomeParentClass = zipfile.ZipFile # implements only __init__
class SomeParentClass: pass # implements neither __init__ nor __new__

While I would prefer a language construct that didn't require this dance for special casing (or similarly require the programmer to hard-code the dance to a specific implementation of a specific parent class as Guido recommends), at the very least I would suggest that the documentation better reflect this somewhat surprising behavior.

Currently, the documentation states [https://docs.python.org/2/reference/datamodel.html#object.__new__] effectively "Typical implementations of __new__ invoke the superclass’ __new__() method with appropriate arguments." It's left as an exercise to the reader to ascertain what 'appropriate arguments' are, and doesn't communicate that the introduction or omission of __new__ or __init__ to a class hierarchy affects the process by which a class is constructed/initialized.

Greg Smith's blog demonstrates some even more dangerous cases. I don't understand why his concerns weren't addressed, because they seem legitimate, and I agree with his conclusion that the older behavior is more desirable, despite the concerns raised by the OP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1683368>
_______________________________________