Specify methods that are allowed for inference of partially initialized generics
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
Rechercherichtung
Es werden keine Quelldateien oder Tests genannt. Beginne damit, die Beispiele des Vorschlags für leere Container und die scikit-learn-Estimator-APIs zu prüfen, und lies anschließend das verlinkte MyPy-Issue und die TypeAssert-Diskussion. Als abgeschlossen gilt die Einigung darüber, ob Methoden über init hinaus generische Parameter ableiten dürfen, sowie die Definition der akzeptierten Syntax und des Verhaltens.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
The inference of generic types for classes in most type-checkers assume that all the generic types can be inferred from the parameters to __init__. This is not always the case. For example, it is a common pattern to create an empty container class and add elements to it later, e.g.:
a = []
a.append("hello world")
Currently for builtin classes, such as list or dict, this idiom is understood by MyPy, but not by Pyright. Moreover, even MyPy is incapable of applying this type inference to custom types (see https://github.com/python/mypy/issues/13134). As mentioned in that issue, the problem is not only with empty containers, but also with some widely used APIs, such as the Estimator API from scikit-learn and related projects, in which the type of the data used is only known when the fit method is called.
My proposal would be to add functionality to the type system to define which methods can be used to infer generic types, apart from __init__. This could be made for example with a decorator (e.g. allow_generic_inference), so that one can define a method such as:
@allow_generic_inference
def append(value: T):
...
In this case the value of the class generic parameter T could be inferred from append if it was undefined before.
I think this proposal may also be similar to the previously suggested TypeAssert mentioned by @erictraut in https://github.com/python/typing/discussions/1013#discussioncomment-1966238. However I am not completely sure that TypeAssert could do what I explained here. I am also not sure that the proposed TypeAssert syntax is better than a decorator.
I hope you too consider this proposal useful, and I look forward to your feedback.
- Vorherrschende Sprache
- Python
- Sterne
- 1.8k
- Forks
- 302
- Ø Merge
- 23 Std.
- Gemergte PRs (30 T.)
- 8
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus python/typing
-
topic: typing spec
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
-
topic: typing spec
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
topic: documentation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
-
topic: documentation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
-
topic: conformance tests topic: typing spec
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 72/100
Ähnliche Issues
-
bug confirmed issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
open-webui/open-webui#30750 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
OpenwaterHealth/openmotion-bloodflow-app#604 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
good first issue
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100