Experiment with backtracking in the new solver
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 20.6k
- フォーク
- 3.3k
- PR マージ指標
- PR 指標を取得中
説明
Depend on https://github.com/python/mypy/issues/15906. This is a follow-up for series started by https://github.com/python/mypy/pull/15287
Currently when getting both upper and lower bounds for a type variable we randomly choose the lower one. This is not always the best choice and can lead to inference failures. A possible example is:
def dec(fn: Callable[[S, S, int], float]) -> Callable[[S], float]: ...
def f(x: List[float], y: List[T], z: T) -> T: ...
dec(f)
this will infer constraints like
S <: List[float], S <: List[T], T <: float, T :> int
They split into two SCCs each containing one variable {T} and {S}, and the second depends on first one. So we would first solve T = int and then we will get updated constraints for S: S <: List[float], S <: List[int], with the only solution S = <nothing>. At the same time T = float, S = List[float] is a totally valid solution. We could get it by backtracking when we get <nothing> and trying different bound(s) in the previous SCC.
One possible problem I see is that this backtracking is exponential in worst case of inference failure (e.g. due to actual user error). Another problem is that backtracking can make implementation much less readable.
cc @JukkaL
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず issue #15906 と pull request #15287 のフォローアップシリーズを読んで、すでに進行中の solver の変更を理解してください。次に、この issue にある型変数の制約の例を調べ、バックトラッキング実験の範囲をどのように定めるかを判断してください。完了の条件は、合意された設計と、推論の失敗および最悪時の挙動に関する根拠が得られることです。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- compilers, devtools
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 20/100