Type annotations in the stdlib

[sirosen (Stephen Rosen)]

@gpshead

Regardless of all of this, we should get to the point where we run multiple static analyzers on the stdlib as an automated CI/bot job so that we at least have some confidence in what we do author.

This should definitely be the first step, before any policy is set requiring or accepting annotations into the stdlib.

I’m not saying it should be done today but that it should be “queued up” as the first of any proposed changes.

My time has been consumed elsewhere recently, but I have been trying to harmonize typeshed stubs with the jsonschema’s annotations, suss out any typing bugs, and eventually plan to push a py.typed marker and deprecate the stubs.
Such a process is only possible on a small-ish package – let alone a codebase the size and scale of the stdlib – by ensuring that the annotations are internally consistent.

---

IMO, it makes sense to assume that any addition of annotations to the stdlib will be extremely gradual and will need to be checked against the typeshed stubs. It would be nice to be able to have mypy_primer-like feedback about cpython changes. Additions of annotations to stdlib modules stand a much stronger chance of being accepted if they can demonstrate in some way that the impact is negligible, zero, or beneficial (i.e. that analyzers can identify new bugs) for downstream packages.

[srittau (Sebastian Rittau)]

I’m generally in favor of moving the stdlib stubs over to Python eventually and most likely gradually. In fact, I opened an issue about it in the typeshed issue tracker a while back: Thoughts about type hints in the standard library · Issue #5444 · python/typeshed · GitHub

But I consider annotating (parts of) the stdlib and providing type stubs for the stdlib as two separate issues. The former - together with unit tests - serves to ensure the correctness of the stdlib, while the latter serves Python’s users. In my personal experience it’s often better to keep stubs separate from the type annotations in the source code, although some kind of synchronization tool would be useful. Stubs are often quite intricate to best suit the users of an API, but such intricate annotations often hurt readability of the source code - especially when using overloads.

This would be especially true in the case of the stdlib, where fairly well tested - and complicated - stubs already exist in typeshed. Using the annotations from the stubs in the stdlib would probably cause a lot of type conflicts in the beginning. On the other hand, throwing away the existing stubs and using newly added type annotations in the stdlib would be a disservice to users that rely on the advanced annotations in typeshed.

[ofek (Ofek Lev)]

I’d be extremely interested in eventually compiling the stdlib of our internal Python distributions with Mypyc.