Unsoundness with `typing.IO` and friends
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
Rechercherichtung
Beginne mit der Überprüfung des Laufzeitverhaltens von typing.IO, typing.BinaryIO, typing.TextIO und io.BytesIO sowie ihrer Beziehungen zu typeshed und des verknüpften CPython-Issues. Vergleiche die drei vorgeschlagenen Ansätze und dokumentiere oder implementiere eine vereinbarte Spezifikation und Laufzeitrichtung; als abgeschlossen gilt die Aufgabe erst, wenn geklärt ist, wie sich isinstance() und issubclass() verhalten sollen.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
The classes typing.IO, typing.BinaryIO, and typing.TextIO look like they want to be Protocols or ABCs, but in fact they are defined as regular generic classes, both at runtime and in typeshed. However, they are meant to encompass the concrete IO classes defined in the io module, and in typeshed we implement that by having these classes inherit from typing.*IO classes, even though there is no such inheritance at runtime.
This can easily lead to unsound behavior:
import io, typing
def f(x: int | io.BytesIO) -> int:
if isinstance(x, typing.BinaryIO):
return x.fileno()
return x
f(io.BytesIO()) + 1 # boom
Type checkers think BytesIO is a subclass of BinaryIO, because that's how it's defined in typeshed, but in fact it isn't at runtime.
I can see a few solutions:
- Special-case
typing.*IOin the spec and say that type checkers should rejectisinstance()/issubclass()calls involving them. - Deprecate the
typing.*IOclasses and eventually remove them, nudging people to use their own Protocols (or the newio.Reader/io.Writer) instead. This is conceptually clean but may be annoying for a lot of users; the typing classes are nice to use in simple application code. - Make these classes actually (runtime-checkable?) Protocols at runtime, though they would be unwieldily large.
Even if we do (2) or (3) type checkers might still want to do (1) since it will be a while before the relevant runtime changes take effect.
(Noticed this while looking into https://github.com/python/cpython/issues/133492 .)
- 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
-
area: harness bug status: needs-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Human-Agent-Society/reef#625 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 80/100
learningequality/kolibri#15351 · 2 Kommentare ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Name consistency Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
eellak/triplestore#65 · 1 Kommentar ·