python / python/mypy

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

Offen
#20,579 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

feature priority-0-high
Vorherrschende Sprache
Python
Sterne
20.6k
Forks
3.3k
PR-Merge-Kennzahlen
PR-Kennzahlen ausstehend

Beschreibung

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.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Es ist kein Datei- oder Test-Einstiegspunkt benannt. Beginne damit zu untersuchen, wie mypy inferierte Typen und local-partial-types-Fehler als JSON bereitstellen könnte, und verfolge dann, wie ein Migrationstool Variablen, Pfade und Positionen zuordnen könnte. Als abgeschlossen gilt die Aufgabe, wenn ein nutzbares Tool, wo möglich, sichere Annotationen hinzufügt, Imports und Näherungen behandelt und statt abzustürzen überspringt oder warnt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
python
Bereich
tooling
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Veraltet
Klarheit
Muss geklärt werden
Anfängerfreundlichkeit
30/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.