python / python/mypy

Infering return type as a union of all returns in type-checked functions

オープン
#17,307 コメント 5 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

feature
主要言語
Python
スター
20.6k
フォーク
3.3k
PR マージ指標
PR 指標を取得中

説明

Feature

Note: This is different than #4409 and #6646 which aim to change what is considered "annotated" and which functions are type-checked in the first place.

Mypy currently only type-check a function if its considered "annotated", ie: all parameters are annotated, or the return type is present (required for methods w/o parameters). Whilst mypy obviously can't infer a return type if it doesn't type-check the content of a function, I feel like methods that are checked could have their return type inferred as a union of whatever mypy think the type of the returns are.

Here's a very simple example comparing mypy and pyright/pylance
image
(same result in CLI)

Pitch

The idea would be to reduce clutter, and reduce the risk of hiding a useful true return type behind a more vague type.

Maybe there's a performance concern for libraries? (mypy having to read more code instead of stopping at a return annotation) How much is it? How much does caching help?

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

実装ファイルやテストは指定されていません。まず、mypy が関数を型チェックするかどうかをどのように判断し、明示的な戻り値アノテーションをどのように処理するかを追跡し、次にその動作を issue の例および参照されている issues と比較してください。チェック対象の関数が戻り値の各式の union を推論し、パフォーマンスとキャッシュへの影響を理解できれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
python
領域
compilers
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
おおむね明確
初心者へのやさしさ
30/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。