I’d like us to think carefully about this.
I agree that this might be nice for “simple” type annotations, where an argument can e.g. only be a str
or whatever. But I’d be wary of starting a large-scale project to add type hints in lots of places.
As a typeshed maintainer and a codeowner for typing.py
, I’m obviously pro-typing. But I’ve also seen how “apparently simple” functions can get very complicated to add annotations for. There will be a lot of functions where we won’t be able to add type annotations without it becoming overwhelming, and it might be pretty confusing for some people to see that some functions in a certain file are fully annotated whereas others have no annotations at all.
Until the stdlib has “type annotation coverage” matching typeshed, type checkers will also have to continue using the typeshed stubs for type-checking user code; they’ll essentially ignore any type hints in the runtime stdlib. That might be highly confusing for end users, if the annotations in the stdlib and the annotations in typeshed diverge for some reason. We’d have to think carefully about how to keep the annotations in the two repos in sync (unless the long-term goal is to get rid of the stdlib stubs from typeshed altogether).