Conformance test: make dataclass_hash.py not rely on `typing.Hashable`?
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 1.8k
- フォーク
- 302
- 平均マージ
- 23時間
- マージ済み PR(30日)
- 8
説明
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.
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
conformance/tests/dataclasses_hash.py から始め、その Hashable ベースの assertions を、issue に記載されている dataclass の hash 動作と比較します。参照されている typing.Hashable と object のアノテーションを読み、その後、既存の conformance の期待事項を確認します。完了条件は、test が typeshed の Hashable 定義に依存せず、dataclass hash の結果を直接チェックすることです。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- testing-qa
- issue の種類
- リファクタリング
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100