Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Create tool to help migration to --local-partial-types #20579

Open
@JukkaL

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:

  1. Run mypy without --local-partial-types but with an extra flag that will dump all inferred types into a json file.
  2. Run mypy with --local-partial-types with an extra flag that will dump information about all "Need type annotation" errors to another json file.
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

        AltStyle によって変換されたページ (->オリジナル) /