Cannot access "__init__" directly

[gsakkis]

Calling __init__ explicitly is a valid (albeit uncommon) pattern, for example after calling explicitly __new__; however mypy considers it an error:

from __future__ import annotations


class Foo:
    def __init__(self, a: int):
        self.a = a


class Bar(Foo):
    def __new__(cls, a: int) -> Bar:
        self = super().__new__(cls)
        # ....
        self.__init__(a)
        # ....
        return self


if __name__ == '__main__':
    print(Bar(1))

[hauntsaninja]

Interestingly, this check goes back to 2013 (and beyond, in Alore). See the reasoning here: #89
The error message isn't great, so I would accept a PR improving it

[gsakkis]

I'm not sure I'm following the reasoning in the mentioned ticket but from a quick code search there seem to be quite a few cases of calling __init__ directly, a lot of them to initialize an instance created with __new__.

As an exception, it is valid to use super() to access __init__ (we know the exact method to call).

Even this exception is limited:

    def __init__(self, a: int):
        # this typechecks
        super().__init__(a)

        # this doesn't
        s = super()
        s.__init__(a)

[hauntsaninja]

mypy does not complain about e.g. concrete_type.__init__(...) which is what many of your code search examples are. For example, mypy will allow:

- self.__init__(a)
+ Bar.__init__(self, a)

Here's a more explicit example of the unsoundness that mypy is avoiding:

class A:
    def __init__(self, x: int): ...
class AA(A):
    def __init__(self, x: int, y: str): ...

def foo(a: A):
    a.__init__(5)

a: A = AA(5, "5")
foo(a)  # boom

[gsakkis]

Thanks for the example, this makes sense. Still I would argue that reporting an error for s = super(); s.__init__() or s = super().__new__(cls); s.__init__() is a false positive according to the reasoning for the exception in #89 ("we know the exact method to call").

[gsakkis]

Another case this comes up: calling __init__ from __setstate__.

I'd argue for reopening this issue; the (main) problem was not the error message.

[JeanOlivier]

I'd also argue for reopening this issue.

I found this issue by googling Cannot access "__init__" directly  after implementing a __setstate__ method and being confused by the error message.

I think it should at least not generate this error message when called from a __setstate__  method, or uising self.
It's also not hard to imagine a valid (even if contrived) case for calling __init__ after initialization even outside of __setstate__, let's say for a "reset object state" feature.

Doing something like:

class Foo():

    def __init__(self) -> None:
        ...

    def __setstate__(self, state: dict) -> None:
        getattr(self, '__init__')()

might circumvent the error message in mypy, but it's not elegant.

[hauntsaninja]

Given the improved error message that explains the unsoundness, I'm not going to reopen this. If you want a type-safe workaround, Foo.__init__(self, ...) will work in __setstate__ as well as anywhere else this comes up, like I mention above. And as always, # type: ignore isn't the worst thing in the world