Conformance test: make dataclass_hash.py not rely on `typing.Hashable`?
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Refactoring
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- python
- Bereich
- testing-qa
Rechercherichtung
Beginne mit conformance/tests/dataclasses_hash.py und vergleiche dessen auf Hashable basierende Assertions mit dem im Issue beschriebenen Hash-Verhalten von dataclass. Lies die referenzierten typing.Hashable- und object-Annotationen und überprüfe anschließend die bestehenden Conformance-Erwartungen. Erledigt ist die Aufgabe, wenn der Test das Ergebnis von dataclass hash direkt prüft, ohne von der Hashable-Definition von typeshed abzuhängen.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
I noticed that the conformance test currently enforces a hashability check on dataclasses:
https://github.com/python/typing/blame/6d5c186ea3f45dd80dcad9f172479b270e54966a/conformance/tests/dataclasses_hash.py
If we take the annotation of typing.Hashable and the annotation of object literally, then no type errors should be reported on that file, as typing.Hashable is a protocol that requires a def __hash__(self) -> int method, and object satisfies that protocol regardless of whether the dataclass transform creates its own __hash__ method or not.
I understand that the issue of deciding whether an object is hashable or not in type checkers is a tricky business and there was a lot of pre-existing discussions/proposals around it. This makes me wonder if it's worth doing a dedicated "hashability" section in the spec, and use separate conformance tests to establish how typing.Hashable assignability should be handled. My understanding is that the pre-existing dataclass hash tests is intended to just test about whether the __hash__ method is nullified or not under the dataclass transform, but by testing it via typing.Hashable it kinds of indirectly dictate hashable assignment behaviors as a side effect.
Concretely, what I had in mind was a refactor to dataclasses_hash.py, where we change the current assertions of the form
# This should generate an error because DC1 isn't hashable.
v: Hashable = DC(0)
into something like this:
assert_type(DC(0).__hash__, NoneType) # OK
The new version does not depend on how typing.Hashable gets defined in typeshed, and it (arguably) aligns more directly with the intention of the tests. But I am unsure about how controversial this proposal would be and hence want to get some feedback on it first.
- 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