Łukasz Langa <luk...@langa.pl> added the comment: I'm not sure whether we should downright reject `__init__()` methods. Sadly, they aren't usable at the moment anyway, but they could. Hear me out.
There seems to be a gap in the PEP 544 definition of protocols, i.e. whether `__init__` should be definable as part of a protocol. Currently this isn't specified and it looks like Mypy is ignoring `__init__` in Protocol definitions. Consider this example: https://gist.github.com/ambv/0ed9c9ec5b8469878f47074bdcd37b0c Mypy doesn't consider `__init__()` to be part of a protocol, even though it's an instance method like any other. It is valid (albeit weird) to call it again on an already initialized instance: >>> class C: ... def __init__(self) -> None: ... print('init!') ... >>> c = C() init! >>> c.__init__() init! >>> c.__init__() init! In the linked gist example, Mypy currently ignores `__init__()` but doesn't ignore `get_ball()`, thus incorrectly judging BallContainer and TwoBallContainer to be equivalent. In fact, it only rejects the third ifmain call with `object` because `object` lacks a `get_ball()` method. So... would that be useful? Do we ever want to define protocols on the basis of how their initializers look like? My uninformed intuition is that this might be potentially useful, however I fail to come up with a realistic example here. ---------- nosy: +lukasz.langa _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44807> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
