Beyond just preventing bugs, increased type annotation coverage in Python code is correlated with better IDE experiences and better performance for other tools that depend on type annotations.
In 2025, Meta is partnering with Quansight to improve the quality of types for third-party packages by contributing inline types or writing type stubs, as well as ways to help measure/maintain type annotation coverage, which will hopefully benefit the entire community.
We have come up with a list of top libraries where we think adding coverage can benefit developers, and we would also like to hear from members of the typing community, type stub maintainers and library authors.
Which libraries would you like to see have better coverage? Please comment below if you have any ideas or suggestions.
While the Array API package isn’t commonly downloaded, it’s the probable future of libraries written for NumPy, PyTorch, Tensorflow, etc. In my opinion, it’s more important than it seems.
(Guess this is as good a place as any to thank @jorenham for all his work!)
Measuring type annotation coverage; now that’s interesting! I’ve been looking for a tool that’s able to measure the coverage of the type-tests for a while now, but haven’t been able to find anything. Is this also what you’re talking about here? Or are you talking about measuring something like the “% of the public API that with type annotations”?
I’d say Numba, which has no typing coverage at all. As far as I can tell, there aren’t any human-made stub-packages out there. If I ever find the time to do so (which doesn’t feel very likely at the moment), I might even have a go at it myself.
Wagtail is also on my typing wish-list, which, thanks to the very impressive django-stubs (shoutout to @sobolevn), might even be possible to do now.
And last time I checked, pyscript and pyodide were also untyped. For what it’s worth, typing these two is probably a lot easier than typing numba or wagtail.
I think there’s a lot to gain in terms of usability and maintainability from typing the scientific ecosystem. In particular, make generic versions of objects like numpy arrays (so you can have something that looks like X: Array[Float32, UInt32] and y: Array[Classes], where Classes might be the levels of your variable) and DataFrames like Polars and pandas (so you can have df: DataFrame[Users], where Users is a class defined somewhere else - perhaps even in your backend or another application.
There are also challenges for popular C++ projects that are packages as Python wheels, where they need to generate Python types for a C++ API. OpenCV is one example and has over 80k stars on GitHub. In this issue input types are not properly preserved across a lot of generic functions
I am working on boto3-stubs project for quite a while. It provides type annotations for boto3 and botocore. There are also types-aiobotocore and types-aioboto3 packages for unofficial AWS SDKs
Since boto3 is the most downloaded package on PyPI, this package improves type coverage for a large amount of projects.
However, there are some issues:
PyCharm still has a bug that causes high CPU usage on @overload functions with Literals (this is the reason why boto3-stubs-lite exists)
building types for a specific version of boto3 requires some extra work for a user, and is not consistent with how you usually use 3rd party type annotations
usually it is impossible to check with keys in botocore output structures are required or optional. The best way is manually mark them.
I would be happy if someone could help me to improve the project.
