# Type annotations in the stdlib **URL:** \ **Category:** Core Development\ **Tags:** typing\ **Created:** [November 28, 2022, 2:44pm UTC](https://discuss.python.org/t/type-annotations-in-the-stdlib/21487 "2022-11-28T14:44:51Z")\ **Posts on this page:** 1\ **Showing post:** 16
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [November 29, 2022, 8:54pm UTC](https://discuss.python.org/t/type-annotations-in-the-stdlib/21487/16 "2022-11-29T20:54:47Z")
> [@pf\_moore](#): > > In my experience, fully type hinted libraries where the types are exposed in the documentation often end up with long and complex type hints that _harm_ readability rather than helping. I think that depends on how you display them. For instance, `sphinx.ext.autodoc` has [multiple options](https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_typehints) for how to display type information. It would be totally possible to list the type information optionally via a toggle, via a collapsed-by-default drop-down at the end of the callable, etc. That would let those who want the type info to have them easily available while making quick glances and general reading not have them get in the way visually. > [@Glenn](#): > > Types in stdlib would slow compilation. That is enough reason to keep them in typeshed forever. “Compilation” of what specifically? If you’re talking about `.pyc` files then it’s negligible and cached. Plus with [PEP 649](https://peps.python.org/pep-0649/) now [tentatively accepted](https://discuss.python.org/t/pep-649-deferred-evaluation-of-annotations-tentatively-accepted/21331), that also helps deal with any overhead which typically shows up from importing. --- _[View the full topic](https://discuss.python.org/t/type-annotations-in-the-stdlib/21487)._