Summary
When a subclass overrides an annotated base-class method but omits annotations from the overriding method's parameters, Pyrefly infers those parameters as Unknown. Pyrefly should use the corresponding parameter types from the base-class signature as inference defaults when the override is unambiguous.
This affects both type checking within the method body and language-server features such as hover information.
Reproduction
Sandbox Link
from typing import reveal_type
class Base:
def process(self, value: str, count: int) -> None:
pass
class Child(Base):
def process(self, value, count):
reveal_type(value) # Pyrefly: Unknown
reveal_type(count) # Pyrefly: Unknown
With Pyrefly 1.2.0, pyrefly check repro.py reports:
INFO revealed type: Unknown [reveal-type]
INFO revealed type: Unknown [reveal-type]
The Pyrefly LSP likewise shows Unknown when hovering over value or count.
Expected behavior
Pyrefly should infer:
An explicit annotation on the overriding method should continue to take precedence. Return types should continue to use normal return-type inference rather than being inherited from the base method.
A conservative initial rule could match Pyright's documented behavior: inherit parameter types only when the base method is not overloaded and the child method has the same parameter names and shape. The inherited signature should be specialized for the subclass before its parameter types are used.
Pyright documents this behavior under Parameter Type Inference.
Motivation
An overriding method is constrained by the callable contract established by its base class. When the child omits an annotation, using the corresponding base parameter type is a safe and useful default: it preserves substitutability while avoiding duplicated annotations. A child can still provide an explicit wider parameter type where contravariance is intentional.
This is especially useful for overrides that add behavior before or after a super() call while otherwise preserving the base method's signature. Inferring Unknown discards type information that is already available and weakens diagnostics, completion, and hover information throughout the overriding method's body.
This request concerns the semantic types used for checking and language-server features. Whether a strict annotation-completeness rule should still report that the annotations are syntactically absent can be considered separately.
Related open issues
- #1174 requests contextual parameter and return inference for an unannotated overload implementation, rather than an overriding method.
- #846 concerns an inherited attribute annotation and an inlay-hint mismatch, rather than method parameters.
- #4548 concerns
explicit-any diagnostics on explicitly annotated overrides, rather than inference for omitted annotations.
I did not find an open issue specifically covering parameter-type inference from a matching base-class method signature.
Environment
- Pyrefly: 1.2.0
- Reproduced in both the CLI (
reveal_type) and the Pyrefly LSP
Summary
When a subclass overrides an annotated base-class method but omits annotations from the overriding method's parameters, Pyrefly infers those parameters as
Unknown. Pyrefly should use the corresponding parameter types from the base-class signature as inference defaults when the override is unambiguous.This affects both type checking within the method body and language-server features such as hover information.
Reproduction
Sandbox Link
With Pyrefly 1.2.0,
pyrefly check repro.pyreports:The Pyrefly LSP likewise shows
Unknownwhen hovering overvalueorcount.Expected behavior
Pyrefly should infer:
An explicit annotation on the overriding method should continue to take precedence. Return types should continue to use normal return-type inference rather than being inherited from the base method.
A conservative initial rule could match Pyright's documented behavior: inherit parameter types only when the base method is not overloaded and the child method has the same parameter names and shape. The inherited signature should be specialized for the subclass before its parameter types are used.
Pyright documents this behavior under Parameter Type Inference.
Motivation
An overriding method is constrained by the callable contract established by its base class. When the child omits an annotation, using the corresponding base parameter type is a safe and useful default: it preserves substitutability while avoiding duplicated annotations. A child can still provide an explicit wider parameter type where contravariance is intentional.
This is especially useful for overrides that add behavior before or after a
super()call while otherwise preserving the base method's signature. InferringUnknowndiscards type information that is already available and weakens diagnostics, completion, and hover information throughout the overriding method's body.This request concerns the semantic types used for checking and language-server features. Whether a strict annotation-completeness rule should still report that the annotations are syntactically absent can be considered separately.
Related open issues
explicit-anydiagnostics on explicitly annotated overrides, rather than inference for omitted annotations.I did not find an open issue specifically covering parameter-type inference from a matching base-class method signature.
Environment
reveal_type) and the Pyrefly LSP