Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Conformance test: make dataclass_hash.py not rely on `typing.Hashable`?

Ouverte
#1,765 2 commentaires 2 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
35/100
Type d'issue
Refactorisation
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
python
Domaine
testing-qa

Piste de recherche

Commencez par conformance/tests/dataclasses_hash.py et comparez ses assertions basées sur Hashable avec le comportement de hash de dataclass décrit dans l’issue. Lisez les annotations référencées de typing.Hashable et object, puis examinez les attentes de conformance existantes. C’est terminé lorsque le test vérifie directement le résultat de dataclass hash sans dépendre de la définition de Hashable de typeshed.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

topic: conformance tests

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.

Langage dominant
Python
Étoiles
1.8k
Forks
302
Merge moyen
23 h
PR mergées (30 j)
8

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de python/typing

Toutes les issues de python/typing

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.