I think this is very much needed PEP, and using mypy for reference implementation is a good idea because mypy actually already (mostly) supports this under the hood.
The only non-trivial question is whether we should allow type applications only to references that are statically known to refer to a function, or do we want to support type application to an arbitrary expression that happen to have a callable-like type inferred? For example:
T = TypeVar("T")
class Callbacks(TypedDict):
regular: Callable[[int], int]
generic: Callable[[T], T]
def test(cb: Callbacks) -> None:
cb["generic"][int] # <- should we support this?
If we only want to support static references, then implementation is trivial, essentially:
- Make this error conditional on Python version <3.15 and file being not a stub.
- Update this helper to accept a
Decorator.
However, if we want to support arbitrary expressions, it should be quite easy as well. Luckily, all the necessary infrastructure was added for TypeForm PEP support. We can use TypeCheckerAsSemanticAnalyzer adapter to re-interpret arbitrary expression as type during type checking.
cc @JukkaL @Gobot1234 @PabloRuizCuevas
I think this is very much needed PEP, and using mypy for reference implementation is a good idea because mypy actually already (mostly) supports this under the hood.
The only non-trivial question is whether we should allow type applications only to references that are statically known to refer to a function, or do we want to support type application to an arbitrary expression that happen to have a callable-like type inferred? For example:
If we only want to support static references, then implementation is trivial, essentially:
Decorator.However, if we want to support arbitrary expressions, it should be quite easy as well. Luckily, all the necessary infrastructure was added for
TypeFormPEP support. We can useTypeCheckerAsSemanticAnalyzeradapter to re-interpret arbitrary expression as type during type checking.cc @JukkaL @Gobot1234 @PabloRuizCuevas