# Call For Suggestions: Nominate Python Packages for Typing Improvements **URL:** \ **Category:** Typing\ **Created:** [February 10, 2025, 3:16pm UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186 "2025-02-10T15:16:27Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![yangdanny97](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/yangdanny97/32/20192_2.png) [@yangdanny97](https://discuss.python.org/u/yangdanny97)\ **Post date:** [February 10, 2025, 3:16pm UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/1 "2025-02-10T15:16:27Z")
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. [About a third of the top 2000 downloaded packages on PyPI do not have any type annotations](https://discuss.python.org/t/type-coverage-of-popular-python-packages-and-github-badge/63401), and many packages that have annotations have incomplete coverage. This represents an opportunity to significantly improve type coverage across the Python ecosystem, with all of its associated benefits for developers that depend on typechecking. 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. @lolpack @MarcoGorelli ---
**Author:** ![beauxq](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/beauxq/32/15042_2.png) [@beauxq](https://discuss.python.org/u/beauxq)\ **Post date:** [February 10, 2025, 6:00pm UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/2 "2025-02-10T18:00:23Z")
The library that has bothered me the most not having typing is kivy. ---
**Author:** ![NeilGirdhar](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/neilgirdhar/32/5776_2.png) [@NeilGirdhar](https://discuss.python.org/u/NeilGirdhar)\ **Post date:** [February 10, 2025, 10:16pm UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/3 "2025-02-10T22:16:41Z")
Great initiative!! For me, my top two projects that I would like to see get some resources would be - The Array API whose annotations are [being developed here](https://github.com/data-apis/array-api-typing/), and - Scipy whose annotations are [being developed here](https://github.com/scipy/scipy-stubs/). 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!) ---
**Author:** ![jorenham](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jorenham/32/27806_2.png) [@jorenham](https://discuss.python.org/u/jorenham)\ **Post date:** [February 11, 2025, 3:03am UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/4 "2025-02-11T03:03:45Z")
> [@NeilGirdhar](#): > > (Guess this is as good a place as any to thank @jorenham for all his work!) You’re very welcome! And in case you were wondering; I don’t plan on stopping anytime soon 🙂 ---
**Author:** ![jorenham](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jorenham/32/27806_2.png) [@jorenham](https://discuss.python.org/u/jorenham)\ **Post date:** [February 11, 2025, 3:26am UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/5 "2025-02-11T03:26:48Z")
> [@yangdanny97](#): > > ways to help measure/maintain type annotation coverage 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”? > [@yangdanny97](#): > > Which libraries would you like to see have better coverage? Please comment below if you have any ideas or suggestions. I’d say [Numba](https://github.com/numba/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](https://github.com/wagtail/wagtail) is also on my typing wish-list, which, thanks to the very impressive [django-stubs](https://github.com/typeddjango/django-stubs/) (shoutout to @sobolevn), might even be possible to do now. And last time I checked, [pyscript](https://pyscript.net/) and [pyodide](https://github.com/pyodide/pyodide) were also untyped. For what it’s worth, typing these two is probably a lot easier than typing numba or wagtail. ---
**Author:** ![baggiponte](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/baggiponte/32/11060_2.png) [@baggiponte](https://discuss.python.org/u/baggiponte)\ **Post date:** [February 11, 2025, 1:37pm UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/6 "2025-02-11T13:37:29Z")
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. ---
**Author:** ![johnthagen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/johnthagen/32/3780_2.png) [@johnthagen](https://discuss.python.org/u/johnthagen)\ **Post date:** [February 11, 2025, 1:59pm UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/7 "2025-02-11T13:59:31Z")
We recently hit issues with static typing in **Numpy** 2.2 - [Overview issue: Typing regressions in NumPy 2.2 · Issue #28076 · numpy/numpy · GitHub](https://github.com/numpy/numpy/issues/28076) - [Issues related to numpy · Issue #18343 · python/mypy · GitHub](https://github.com/python/mypy/issues/18343) 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 - [Python return types in 4.10 break type checking due to not depending on input types · Issue #25713 · opencv/opencv · GitHub](https://github.com/opencv/opencv/issues/25713) ---
**Author:** ![deanm0000](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/deanm0000/32/25843_2.png) [@deanm0000](https://discuss.python.org/u/deanm0000)\ **Post date:** [February 11, 2025, 3:55pm UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/8 "2025-02-11T15:55:25Z")
Pyarrow with a shout out to [GitHub - zen-xu/pyarrow-stubs: Type annotations for pyarrow](https://github.com/zen-xu/pyarrow-stubs) Xlsxwriter ---
**Author:** ![vemel](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vemel/32/25962_2.png) [@vemel](https://discuss.python.org/u/vemel)\ **Post date:** [February 15, 2025, 8:20am UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/9 "2025-02-15T08:20:43Z")
I am working on [boto3-stubs](https://pypi.org/project/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](https://pypi.org/project/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. ---
**Author:** ![yangdanny97](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/yangdanny97/32/20192_2.png) [@yangdanny97](https://discuss.python.org/u/yangdanny97)\ **Post date:** [February 24, 2025, 5:59pm UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/10 "2025-02-24T17:59:27Z")
Thanks for all the suggestions everyone, this has been very helpful! We’ve started reaching out to maintainers and creating PRs, notably with some good progress in [pandas-stubs](https://github.com/pandas-dev/pandas-stubs/pulls?q=is%3Apr+marcogorelli+is%3Aclosed) by @MarcoGorelli. We’ll start reaching out to more maintainers in this thread in the coming weeks to learn more about workflow and pain points. In the short-term, we plan to make more direct contributions to packages related to the scientific stack, but we’re also looking at opportunities to build tools/automation that could useful for everyone. ---
**Author:** ![MarcoGorelli](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/marcogorelli/32/21241_2.png) [@MarcoGorelli](https://discuss.python.org/u/MarcoGorelli)\ **Post date:** [March 11, 2025, 11:39am UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/11 "2025-03-11T11:39:12Z")
> [@yangdanny97](#): > > notably with some good progress in [pandas-stubs](https://github.com/pandas-dev/pandas-stubs/pulls?q=is%3Apr+marcogorelli+is%3Aclosed) by @MarcoGorelli. Thanks - some of this work landed in the [new release](https://pypi.org/project/pandas-stubs/2.2.3.250308/) from this week, which resolves several issues related to untyped arguments (e.g. I was pleased to see CI fail in [Narwhals](https://github.com/narwhals-dev/narwhals/pull/2172/files) when the newest pandas-stubs release meant that some `# type: ignore`s were no longer neccessary) Hats off to the main pandas-stubs maintainer (Irv Lustig) for keeping things moving quickly and providing great feedback! ---
**Author:** ![Jos\_Verlinde](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jos_verlinde/32/25571_2.png) [@Jos\_Verlinde](https://discuss.python.org/u/Jos_Verlinde)\ **Post date:** [March 14, 2025, 11:04am UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/12 "2025-03-14T11:04:58Z")
Sharing my response to Danny in the Pyscript repo here for visibility: There is an initial release for the webassembly port of MicroPython that including an initial stub for the `pyscript` module that is released to PyPI : [micropython-webassembly-stubs · PyPI](https://pypi.org/project/micropython-webassembly-stubs/) That is based on the MicroPython specific tools I created, and parttly stubs created by `pyright --createstub` The challenge is to create processes and tools to maintain consistent stubs and documentation without increasing the efforts, or complexity to do so for all maintainers. Missing typing finctionality: One thing that is missing specifically for micropython is that today it is not possible for type checkers to select on the MicroPython version, nor on the port (webassembly in this context) So rather than maintain one set of stubs with conditions, multiple packages are needed, increasing the complexity for both maintenance and use IDE Tooling: to simplify maintenance - IDEs could / should provide better support for mixed language files: - `.c` file with embedded documentation in .RsT or .md and Python samples - `.pyi` file with embedded .RsT /MD with embedded Python samples ---
**Author:** ![erictraut](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/erictraut/32/15190_2.png) [@erictraut](https://discuss.python.org/u/erictraut)\ **Post date:** [June 16, 2025, 2:20am UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/13 "2025-06-16T02:20:46Z")
It’s exciting to see [the progress](https://engineering.fb.com/2025/05/05/developer-tools/enhancing-the-python-ecosystem-with-type-checking-and-free-threading/) here. Augmenting and improving the type information in top libraries helps the entire ecosystem, so this work is very impactful! Thanks to all who are contributing to this initiative. > [@jorenham](#): > > Measuring type annotation coverage; now that’s interesting! In case you’re not already aware, I added a feature to pyright a while ago that allows library and stub authors to find places where they are missing type annotations within their library’s public interface. The `pyright --verifytypes` command will also generate a “type completeness” score from 0 to 100%. I guess this isn’t the same as measuring the coverage of type tests, but it should give you some insight into the coverage. Documentation can be found [here](https://microsoft.github.io/pyright/#/typed-libraries?id=verifying-type-completeness). If you see ways to improve this tool, let me know. ---
**Author:** ![jorenham](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jorenham/32/27806_2.png) [@jorenham](https://discuss.python.org/u/jorenham)\ **Post date:** [June 16, 2025, 4:19pm UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/14 "2025-06-16T16:19:34Z")
> [@erictraut](#): > > In case you’re not already aware, I added a feature to pyright a while ago that allows library and stub authors to find places where they are missing type annotations within their library’s public interface. The `pyright --verifytypes` command will also generate a “type completeness” score from 0 to 100%. I guess this isn’t the same as measuring the coverage of type tests, but it should give you some insight into the coverage. Documentation can be found [here](https://microsoft.github.io/pyright/#/typed-libraries?id=verifying-type-completeness). If you see ways to improve this tool, let me know. Pyright’s `--verifytypes` is indeed a very useful tool. If I understand correctly, the “type completeness” is the relative number of public(?) symbols in the Python sources that Pyright is able to fully determine the type of. Did I get that right? @MarcoGorelli recently suggested that we might be able to use this score in NumPy to help us prevent typing-related regressions. His idea was to requiring a certain lower bound on the type completeness score in CI. Ideally that would be 100%. But at the moment there are parts of the NumPy’s (mostly `numpy.ma`) that are not fully annotated yet. And since `--verifytypes` will fail for any score below 100%, it would require a custom wrapper script. Another challenge is that we weren’t able to get pyright to exclude certain irrelevant parts of the codebase such as the unit tests (which live in-project in numpy). The `exclude` config does not seem to be used by `--verifytypes`, and there is also no `# pyright: ignore[reportVerifyTypes]` or something.To illustrate, running `pyright --ignoreexternal --verifytypes numpy` (without the wrapper script, and with `pyright==1.1.402`) on the current `main` branch of numpy, the type completeness score is something like 44%. But the majority of the reported errors are related to the tests. So if we would require a score of e.g. \>40% now, then adding unit tests could cause the CI to fail because it would misinterpret this as a typing regression. This is something a wrapper script could also work around. But I can imagine that we’re not the only ones that would find it useful if `--verifytypes` was able to exclude certain parts of the relevant codebase. * * * When I was talking about “type coverage” in my earlier post, I was thinking of an analogue to “testing coverage” metrics that tools like [coverage.py](https://coverage.readthedocs.io/en/latest/) provide. In NumPy, we the bundled stubs using type-tests. Specifically, we have a collection of `.pyi` files (in [`numpy/typing/tests/data`](https://github.com/numpy/numpy/tree/main/numpy/typing/tests/data)) that use `typing.assert_type` for acceptance testing (the `reveal` subdirectory), and `.pyi` files with `# type: ignore`s for rejection testing (the `fail` subdirectory). This way, “running” the tests is the same as running the static type-checker (currently only mypy). So what I had in mind when I heard “type coverage”, was something like the % of the stubs that are covered by these type-tests, analogous to the (runtime) test coverage of e.g. coverage.py. * * * In case of libraries with cpython extensions a different form of “type coverage” could also be useful: The % of (public) symbols that are “covered” by stubs (or inline annotations). But I believe that pyright won’t be able to detect it if some public module that’s purely written in C has no annotations. In case of NumPy, there’s quite a lot of C code, so there’s a chance that Pyright’s current “type completeness” score is too optimistic. But I understand that such a feature would require pyright to be equipped with stubtest-like runtime capabilities, which I’m guessing is considered to be out-of-scope for Pyright. ---
**Author:** ![yangdanny97](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/yangdanny97/32/20192_2.png) [@yangdanny97](https://discuss.python.org/u/yangdanny97)\ **Post date:** [October 6, 2025, 10:34pm UTC](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/15 "2025-10-06T22:34:07Z")
@MarcoGorelli recently wrote a blog post on getting Numpy’s type completeness from 33% at the beginning of the year to nearly 90% today 🙂 > **[Bringing NumPy's type-completeness score to nearly 90% | Pyrefly](https://pyrefly.org/blog/numpy-type-completeness/)** > > We tell the story of how we brought NumPy's type-completeness score from ~33% to nearly 90%