-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Description
Mypy 2.0 will have --local-partial-types enabled by default, but turning it on often requires some migration work. I believe that we can automate most of this work pretty easily (and that we should, due to the large user impact otherwise).
This example shows the main issues users will encounter:
a = [] # "Need type annotation" if using --local-partial-types def f() -> None: a.append(1) class C: x = None # "Need type annotation" if using --local-partial-types def __init__(self) -> None: self.x = 1 reveal_type(a) # list[int] (list[Any] if using --local-partial-types) reveal_type(C.x) # int | None (Any | None uf using --local-partial-types)
To fix the errors, explicit annotations are needed for a and x. However, figuring out the precise types can be non-trivial by just reading the code in complex use cases.
A tool could automatically add the necessary type annotations, and preferably use the types mypy can infer when the flag is not used.
Here's a way we could probably do it:
- Run mypy without
--local-partial-typesbut with an extra flag that will dump all inferred types into a json file. - Run mypy with
--local-partial-typeswith an extra flag that will dump information about all "Need type annotation" errors to another json file. - The tool will take the two json files as input and add annotations to all relevant files based on the previously inferred types.
There are a few things that could cause issues:
- We should probably record the full names of variables and also the absolute paths of each file in the json so that we can reliably find all the necessary information. We need to be able to match these things reliably: inferred type, variable name, file path and location.
- We should probably add imports for the types. These could introduce cyclic imports, however. Maybe we'll these for the user to resolve.
- Added imports could also create conflicts with other names defined in the file. Possibly detect aliasing issues and import relevant names using a name prefix.
- Some types may be too difficult to reconstruct (e.g. overloads). In those cases we can print a warning and produce a type that approximates the inferred type.
I think that we can ship the tool with mypy, and it doesn't require a ton of polish, but we should make sure it can be used in large real-world codebases. It's better to skip some variables or fall back to an approximate type instead of just crashing, for example.