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
Is your feature request related to a problem? Please describe.
Currently, when method is overridden, we have to specify types again, even if they match the superclass. This is annoying and also against DRY principle.
Describe the solution you'd like
If a subclass implements a method which is defined in superclass and types are not specified, but otherwise the signature is an exact match, types should be inherited from superclass.
classInterface:
defexample(self, a: str) ->int:
raiseNotImplementedErrorclassImplementation(Interface):
defexample(self, a):
reveal_type(a) # Currently, 'Unknown', should be str# do stuff
Return type similarly have to be re-specified.
Additional context
I'm not sure how re-specified types should be treated, but I guess if any type is re-specified might as well re-specify all types.
The text was updated successfully, but these errors were encountered:
I will point out that I'm considering adding this functionality but primarily for completion suggestions and other language server features, not for static type checking. As I mention in the other thread, there are a bunch of edge cases where the behavior will be undefined, and I don't plan to support those cases. If you are using pyright for static type checking, I encourage you to provide complete annotations for all input parameters.
Is your feature request related to a problem? Please describe.
Currently, when method is overridden, we have to specify types again, even if they match the superclass. This is annoying and also against DRY principle.
Describe the solution you'd like
If a subclass implements a method which is defined in superclass and types are not specified, but otherwise the signature is an exact match, types should be inherited from superclass.
Return type similarly have to be re-specified.
Additional context
I'm not sure how re-specified types should be treated, but I guess if any type is re-specified might as well re-specify all types.
The text was updated successfully, but these errors were encountered: