Pythonの型付けを進化させる
本文の状態
日本語全文を表示中
詳細モードで約3分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Vercel Blog
Python開発チームが、TypeScriptのプログラマブル型に近づけるため、Pythonの型システムをより表現力豊かで組み合わせ可能にする研究を1年間行い、その成果としてPEP 827: 型操作を発表した。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
タイトル: Pythonの型付けの進化
Pythonの型システムをより表現力豊かで構成可能にし、TypeScriptのプログラマブルな型に近い考え方を取り入れつつ、Pythonのランタイムモデルに合わせて慎重に設計した、1年間にわたる研究の成果をお伝えできることを嬉しく思います。その結果がPEP 827: Type Manipulationです。
Pythonのランタイムは非常に強力です。クラス、メソッド、さらにはAPI全体でさえ、わずかなコードから動的に生成できます。メタプログラミングのような概念はクラス宣言を変形させ、デコレータは関数やメソッドに追加の振る舞いを与えることができ、これらはほんの一例に過ぎません。
しかし、Pythonの静的型付けは、型チェッカーのプラグインやボイラープレートコードなしでは、こうした動的な挙動にしばしば「追従」できません。PEP 827は、既存の型をイントロスペクトし、新しい型を構築するための標準的な、型レベルの構成要素を提案しています。これは型チェッカーとランタイムツールの両方を支援するように設計されています。
FastAPIの作者であるSebastián Ramírezは、Python Discourseでの私たちの投稿で、この提案の潜在的な影響を巧みに要約しています。
簡単な例
具体的な例として、TypeScriptのユーティリティ型（PickやOmitなど）が挙げられます。以下は、TypeScriptとPythonで並べて実装したPickです：
TypeScript専用の型構文が簡潔で要点を押さえていることがすぐにわかりますが、言語の他の部分とはかなり異なっています。一方、Pythonは標準的なPythonの命令型構文と型レベルのAPIを組み合わせたものに依存しています。
次に、Omitがどのように実装できるかを見てみましょう：
興味深いことに、Python版の実装はPickの実装により近く、唯一の違いは条件を反転させる点だけです。一方、TypeScript版はかなり異なる方法で構成されており、より深い書き換えが必要です。
これは、大きな目的が「PythonをTypeScriptのように見せる」ことではないことを示しています。目的は、Pythonのセマンティクスに合致し、ランタイムでもイントロスペクト可能なままである、プログラマブルな中核をPythonの型付けに与えることです。これにより、Pydanticのようなフレームワークも恩恵を受けられるようになります。
今後の展開
PEPは議論され、改訂され、時には却下されます。私たちはそのプロセスの一員となれることを嬉しく思い、この研究に投資しました。なぜなら、私たちはTypeScriptとPythonの両方で開発を行っており、両方のエコシステムが繁栄することを望んでいるからです。
こう問う人もいるかもしれません：エージェントがソースコードの作成割合をますます増やしている時代に、プログラミング言語の構文、ツール、型システムの能力など、まだ気にする必要があるのでしょうか？
私たちは、その答えはこれまで以上に「はい」であると主張します。型チェッカーにはより徹底的であってほしいし、フレームワークにはより表現力豊かであってほしい。そうすれば、よりレビューしやすく簡潔なコードを安全にリリースできるからです。維持しなければならないボイラープレートコードは少なければ少ないほど良く、この状況がすぐに変わるとは思っていません。
ですから、そうです。エージェントも気にするでしょう。そして私たちも気にします。
続きを読む
原文を表示
We’re excited to share a year-long research effort aimed at making Python’s type system more expressive and composable, something closer in spirit to the programmable types in TypeScript, but carefully crafted for Python’s runtime model. The result is PEP 827: Type Manipulation.
Python’s runtime is incredibly powerful: classes, methods, and even whole APIs can be generated on the fly from a few lines of code. Concepts like metaprogramming can transform class declarations, decorators can give functions and methods additional behaviors, and those are just a few examples.
But Python's static typing often can’t “follow along” without typechecker plugins or boilerplate code. PEP 827 proposes a set of standard, type-level building blocks for introspecting existing types and constructing new ones, designed to help both type checkers and runtime tooling.
FastAPI creator Sebastián Ramírez summed up the potential impact well on our post in the Python Discourse:
Quick taste
One concrete example is the familiar TypeScript utility types, like Pick and Omit. Here's Pick implemented in TypeScript and Python side by side:
We can immediately see that the TypeScript dedicated typing syntax is short and to the point, albeit quite different from the rest of the language. Python, on the other hand, relies on the standard Python imperative syntax combined with type-level APIs.
Now let's look at how Omit can be implemented:
Interestingly enough, Python's version is more in line with the Pick implementation, the only difference is inverting the condition. TypeScript, on the other hand, composes quite differently, and requires a deeper rewrite.
This illustrates that the big idea isn't "make Python look like TypeScript." It’s to give Python typing a programmable core that matches Python’s semantics and stays introspectable at runtime, so frameworks like Pydantic can benefit too.
What's next
PEPs are debated, revised, and sometimes rejected. We’re excited to be part of that process, and we invested in this research because we build across TypeScript and Python and want both ecosystems to thrive.
One might ask: in an age where agents are writing an increasing share of source code, should we even care about programming language syntax, tooling, or type system capabilities?
We argue the answer is, more than ever, "yes". We want type checkers to be more thorough and frameworks to be more expressive, so that we can safely ship more reviewable, succinct code. The less boilerplate we have to maintain, the better, and we don’t see that changing anytime soon.
So yes, agents will care. And so will we.
Read more
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み