Unify typing for `__path__`?
オープン
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 5.1k
- フォーク
- 2.1k
- 平均マージ
- 1日 19時間
- マージ済み PR(30日)
- 82
説明
After the last mypy update v0.920, I started to notice an inconsistency with how the module variable __path__ is typed mainly across typeshed, mypy, and pyright.
| Type | Link | |
|---|---|---|
typeshed - ModuleType |
MutableSequence[str] |
https://github.com/python/typeshed/pull/6200 |
typeshed - pkgutil.extend_path |
list[str] |
https://github.com/python/typeshed/pull/5222 |
| mypy | list[str] |
https://github.com/python/mypy/pull/9454 |
| pyright | Iterable[str] |
https://github.com/microsoft/pylance-release/issues/1098 |
In the Python docs it's mentioned as:
`__path__` must be an iterable of strings, but it may be empty.
However the docs for pkgutil.extend_path go on say it's mostly a list (?) cpython/pkgutil.py
If the input path is not a list (as is the case for frozen
packages) it is returned unchanged. The input path is not
modified; an extended copy is returned. Items are only appended
to the copy at the end.
From my point of view, it isn't entirely clear what the "correct" type should be. Some points to consider though:
- In most cases it seems to be a
list[str]. - It was mentioned here however that it can sometimes also be a
MutableSequence[str] - The
__path__type should be valid as first argument topkgutil.extend_path. At the moment that only applies tolist[str]but obviously the argument type forextend_pathcould be changed to, for example, accept a TypeVar bound toIterable[str]instead. - It seems to be fairly common (and safe ?) to access the at least the first item of
__path__via__getitem__.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、typeshed の ModuleType と pkgutil.extend_path のアノテーションを、Python のモジュールパスおよび pkgutil のドキュメントと比較し、その後、リンクされている mypy と pyright の議論を確認します。文書化された挙動と観測された挙動を反映する、一貫した型の契約を決定します。影響を受けるスタブ間で関連するアノテーションが一致し、extend_path との互換性を維持していれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- tooling
- issue の種類
- リファクタリング
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 20/100