You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Automatically use Self type even if it doesn't appear in method annotation #14075
fromtypingimportSelfclassC:
x: Selfdefmeth(self) ->None:
self.x=self# E: Incompatible types in assignment (expression has type "C", variable has type "Self")
Although it is unfortunate, technically this is required by PEP 484, that says that if no annotation is given, self has a type of current class (note also we can't bind self type for self.x expression giving it type C, as this will open another unsafety). This can be avoided by using e.g. self: Self (or generally Self type anywhere in the signature).
It looks like there can be only two solutions:
Always infer Self type for self. This will cause a big performance penalty and may be surprising for users who are not familiar with Self (if they use reveal_type(self)).
Use some heuristic and only infer Self where otherwise we will have this problem. For example, infer Self if an attribute with type containing Self is used anywhere in a method.
I am leaning towards the latter, but didn't want to do this until we get some more experience.
For what it's worth, pyre and pyright both adopted the former approach. (PEP 673, which introduces the Self type, was authored by the pyre team, and pyre was the reference implementation for it.)
Pyright has had support for Self for about a year now, and we haven't received any questions or complaints about inferring the type Self for self parameters. We likewise infer typeType[Self] for cls parameters.
Reacted by Thomas M Kehrenberg, Paweł Rubin, Ali Hamdan, DevilXD, Alex Waygood, davfsa and Randolf Scholz
I think PEP 484 has not expected to ever be a Self type available at the time of it's writing. I'm also leaning towards just inferring Self by default. If a lack of user experience is factor here, this addition can be delayed until 1-2 Python versions pass, so that the Self type has a chance to "appear in the wild" (as it's fairly new) and for users to gain said experience. Although on the other hand, there's a high chance that someone who's following the typing news, even not regularly, has already heard and learned about the Self type being a thing, so there's not much reasons to even wait. At least that's how I see it in my opinion.
Activity
erictraut commentedon Nov 13, 2022
For what it's worth, pyre and pyright both adopted the former approach. (PEP 673, which introduces the
Selftype, was authored by the pyre team, and pyre was the reference implementation for it.)Pyright has had support for
Selffor about a year now, and we haven't received any questions or complaints about inferring the typeSelfforselfparameters. We likewise infer typeType[Self]forclsparameters.DevilXD commentedon Nov 24, 2022
I think PEP 484 has not expected to ever be a
Selftype available at the time of it's writing. I'm also leaning towards just inferringSelfby default. If a lack of user experience is factor here, this addition can be delayed until 1-2 Python versions pass, so that theSelftype has a chance to "appear in the wild" (as it's fairly new) and for users to gain said experience. Although on the other hand, there's a high chance that someone who's following the typing news, even not regularly, has already heard and learned about theSelftype being a thing, so there's not much reasons to even wait. At least that's how I see it in my opinion.AlexWaygood commentedon Feb 15, 2023
I just closed #14708 as a duplicate of this issue
Rebind self-types in subclass methods without Self annotation (#15541)
Annotate constructor self explicitly for mypy