グリーンフィールドでない限り、漸進的型付けが唯一の方法だよね。いくつかのレガシーPythonコードベースにmypyを使って型ヒントを組み込んだけど、実際に賢い方法はモジュールごとに「オプトイン」することだけだと思う。もしpyreflyがそれをサポートしないなら、使い道はかなり限られると思う。もしかしたら、llmコード生成の方向を狙ってるのかもしれないけど。llmがPythonスクリプトを生成するための、すごく速くて厳密な型チェッカーが役立つのは見えるな。

これは、Typescriptの初期の頃を思い出させるね。既存の大規模プロジェクトにスムーズに導入することに焦点を当てていたから。より制約のある要件（例えばnoImplicitAny）は、一つずつオンにできて、最終的にstrictスイッチを切り替えてすべてのチェックにオプトインすることができた。

漸進的型付けって、コードベースのどこにでもある暗黙の「any」（不明な型）がエラーでも警告でもないってことなんだ。完全に型付けされてると思ってた重要なコードでもね。間違って型バグを導入して、文法や推論の制限で型チェッカーが予期せずにおかしくなって、「このファイルに問題はありません！」って自信満々に言ってくるのが理解できるけど、私がmypyを試したときの最終的な問題は、型からの保護を実際に保証する方法がなかったこと。 「このファイルには漸進性はない、完全に型付けされてる！」って主張する方法が重要だけど、漸進的型付けは移行だけじゃなくて、動的言語でできるクレイジーなことや、静的型付けを重視しない人を怖がらせる誤検知の恐怖とも関係してる。もしかしたら「ソフト」型付けって呼ぶ方が分かりやすいかも。今のところ、漸進的型付けはアンチパターンだと思う。

Pythonを書くためにお金をもらっているけど、Rustプログラマーだと思っているし、徐々に保証される方が理にかなっていると思う。

これ、私にはすごく嫌だな。Pythonに型アノテーションを追加する半分の目的は、エラーが起きやすい動的型付けを抑えることなんだよね。Pythonが許可しているからって、バカなことをした時に気づかないのは嫌だ。だから、動かすコードを大事にする人のために、暗黙のAnyを使わないモードとか「厳格モード」を追加してほしいな。

VSCodeでJupyterノートブック使ってる？普通のPythonファイルと同じpylanceを使うから、使い捨てコードを書くときにはちょっとイライラするんだよね。

他のレスに同意だね。VSCodeのノートブックを使って静的型チェックをするべきだよ。言語サーバーは、ノートブックの統合や「ライブコーディング」を含めて、まさに君が求めていることをやってくれるんだ。

初心者向けのコードを最適化してるとは思わないな。むしろ、レガシーコードの最適化をしてる感じ。大規模な未型付けのコードベースに型チェッカーを導入するのは大変だけど、既存のコードのほとんどが受け入れられれば、負担は少なくなるよね。

そして、型チェッカーがこれを前提とすることは重要です。 でも、なんでそれが重要なの？もし list[int] が必須なら、そこでは型エラーが出るべきだと思うけど。

わからないな。Pythonの型チェックはオプションだから、プログラマーが気にしない限り、型チェッカーも気にしなくていいと思う。もっと面白いケースは、my_list.append(2.45) や my_list.append(Decimal("2.0")) だね。これらは「数値」だけど「整数」じゃない。現実の世界では、CSVデータの行は型チェックされないし、スプレッドシート業界も型付きCSVデータを採用するようにはなってないよ。

それは、そのリストの後に何が起こるかによるね。整数特有の操作が適用されるのか、それともただ表示されるだけなのか？もしそれが、整数を文字列にキャストできるstr属性を持つオブジェクトに渡されたらどうなる？

私はここでのtyの振る舞いに強く反対です。[tyの開発者です] tyはまだ完成していないことに注意してください！この特定の例では、リストリテラルの型を推測するためにtyが特に賢いことをしていないので、つまずいています。要素が何であれ、単に list[Unknown] としてプレースホルダーを推測するだけです。Unknown は段階的な型（Any と同じように）なので、append の呼び出しは成功します。なぜなら、すべての型が Unknown に代入可能だからです。リストのより正確な型を推測する計画はありますが、周囲の文脈でリストに対して何をしているかを考慮するために「双方向」の型付けが必要になるので、予想以上に複雑になるでしょう。それに関するトラッキングの問題はこちらにあります: https://github.com/astral-sh/ty/issues/168

pyreflyの挙動の問題は、大きなコードベースがPythonの型チェックを使っていない場合、このツールを段階的に導入できないことだよね。すべての問題を修正しないといけないから、移行には広範なサポートが必要だよ。Metaの内部ツールならそれでいいけど、エンジニアリングリーダーシップの優先事項にこの種の変更が含まれていない組織でツールを徐々に導入する場合は、もっと受け入れやすい方がいいと思う。だから、tyのやり方が好きなんだ。自分のコードでは、こういう型の混合があったら警告してほしいけどね。

tyの挙動には強く賛成だな。動いているPythonコードが型エラーを出すべきじゃないと思う。ユーザーが型アノテーションを追加して、より静的なサブセットを選択しない限りね。

Pythonがこれを許可しているという事実は全く関係ないよ。俺にとって、typecheckerが暗黙的にlist[int | str]を許可するのは、初心者向けのコードを最適化してるように見える。そうだね、君の意見に基づいてツールを作るより、Pythonで許可されていることに基づこうよ。

list[int | str]は普通は間違いかもしれないけど、my_list = [BarWidget(...), FooWidget(...)]はどう？ my_list.append(BazWidget(...)) my_list.append(7) そこで型チェッカーが、ほぼ確実にlist[Widget]として意図されている型ヒントを推測できて、最初のappendを許可して、二つ目をフラグできたらいいと思わない？

@TODOとして明示された型を見たときは笑っちゃったけど、考えてみると、実は結構いいアイデアだね！

ちょっと別の質問だけど、Rust開発のその側面に詳しい君に聞きたいことがあるんだ。「Rust用のスクリプト言語」の話が何度か出てきたけど、Rustの構文にうまくフィットして、Rustと一緒にコンパイルできて、Rustの型をネイティブにインポートできて、でもコンパイルや実行、ホットリロードが早い言語って知ってる？君のネットワークでそのことに取り組んでいる人がいるかどうか教えてほしい。そして、構文の部分を除けば、Pythonがその隙間を埋める可能性はあると思う？

あのMarkdownスタイルのテスト、めっちゃ好き！テストがドキュメントとしても機能する素晴らしいアイデアだと思う。どうやってこの解決策を思いついたのか教えてくれる？Rustのドキュメントのコード例からインスパイアされたの？

この2つにはすごく興味があるよ。TypeScriptの世界から来たから、型推論の有無や交差型、型の絞り込みなど、いろんな方向性に興味津々。Python開発者としては、4つ以上の型チェッカーがあって、それぞれ動きが違うのに疲れ果ててる。ほんとにPythonらしいよね。でも、これらのプロジェクトにはすごく興味を持って追ってる。結局のところ、良い型チェッカーはコードをもっと早く、信頼性高く書けるようにしてくれるはずなんだけど、今のPythonの型チェックの状態ではそうなってない気がする。プロジェクト頑張ってね！

今のところ、Pythonプログラムの型チェックにかける労力は、Pythonからちゃんとした型システムを持つ言語に移行する方が良いと思ってる。Interopを使えば、Pythonが必要な部分や人はそのままPythonでいられるしね。もちろん、いつも可能ってわけじゃないけど、Pythonを無理やり使おうとすると時間がかかりすぎるよ。

Pythonは、私の知る限り、多くの機能を持っていて、非常に寛容なランタイムだけど、（C++と似て）コードを管理しやすくするためには、限られたサブセットだけを使うべきだと思う。残念ながら、そのサブセットは誰に聞くか、何を目指すかによって違うんだよね。私が自分のコードベースで使いたくないPythonのサブセットについて話すと、メタクラス、デスクリプタ、__call__を使った呼び出し可能オブジェクト、object.new(cls)、名前が名前マングリングのルールを引き起こすこと、self.__dict__などがある。私の意見では、これらの機能は魔法がかかりすぎていて、コードの理解を妨げると思う。

その投稿のトップコメントが、全てのナンセンスをすぐにしっかり否定してるね：> もしそんな超汎用的な関数があって、型ヒントが強制されているなら、Anyを使って気にしないでおけばいい。バカな例だけど、ライブラリのslow_add関数の文脈でも、作者は最初に人々が非数値の値を渡すとは思ってなかったかもしれないから、次のバージョンアップでハードコーディングされたtime.sleep(0.1)の代わりにtime.sleep(a / b)にしたら、今度は文字列やタプルを渡したユーザーがクラッシュすることになっちゃった！もしその関数が数値の値だけに使うことを意図していると宣言できる方法があれば、予期しない使い方をしたユーザーのために後方互換性を持たせる必要がなくなるのに。私の意見では、非対話的に動作するPythonに対しては、型チェックは当たり前だよ。型チェックを追加しない選択をするのは、明らかに間違いを犯してる。

あなたがその言語を使っていないのに、どうやって意見を形成するのか少し教えてもらえる？特に型に関する議論が、使ったこともない言語に対して人々が怒りをぶつける様子は面白いと思うし、あなたの投稿のように作り話の例を持ち出すのもね。> そこでは、最高の型ツールがあっても、良いプラクティスを確立しない限り問題が起こることを理解するのが目的だと思う。 - どうしてPython開発者がPythonについて理解していないと思うの？彼らはあなたとは違って、その言語を積極的に使ってるのに。

長い投稿を要約するとね：> ライブラリの引数に型ヒントを追加すると、Hyrumの法則に悩まされることになるし、ユーザーの全体像を正確に型付けする準備ができてないってことだよね。それは理解できる。でも、彼らは破壊的な変更をしていて、それはただの破壊的変更の痛みなんだ。もし彼らがこうしていたらほぼ同じことになる：def slow_add(a, b): throw TypeError if !isinstance(a, int) ... でも、そのコードを見たら「まあ、これは破壊的変更だよね、当然文句が出るよ」と言うだろう。ここでの唯一の本当の違いは、これは開発者にとっての破壊的変更であって、実行時に破壊的ではないってこと。Pythonは実行時に型ヒントを強制しないからね。既存のコードは動くけど、コードを見ている既存のツールは失敗する。これは簡単な回避策を提供する（無視するだけでいい）けど、開発者にとっては同じコードが同じ方法で変更される必要があるから、同じように中断されるんだ。--- 対照的に！ライブラリは非常に頻繁に戻り値に型を追加できて、それがユーザーにとってすぐに役立つんだよね。君は出力を既に出力している値だけに制限しているわけで、基本的に定義上、間違ったコードだけが失敗することになる。

多分、たくさんのAIがPythonコードを生成していて、その出力を素早くサニタイズ/バリデートするためにタイプチェッカーが必要なんだろうね。ダイナミック言語は人間が理解するのも大変なのに、AIエージェントはもっと苦労してると思うよ。

Instagramはエラーを修正できるリンターを作ったんだけど、これはflake8やpylintよりも改善されてるよ： https://github.com/Instagram/Fixit でも、Ruffはそれをさらに上回る改善なんだ。