プログラム言語Pythonの設計者として最も有名なGuido van Rossum氏が先日，Pythonの関数宣言に型アノテーション(Type Annotation)を追加するという提案を，python-ideaメーリングリストに向けて発信した。提案では，Pythonの動的型付けという性格やインタプリタの動作は変更せず，静的型付けによるメリットを提供することを目指している。
サードパーティモジュールに(あるいはstdlibにも)型チェック用のアノテーション記述を追加可能にすると同時に，そのコードを修正することなく，(未修正の)Python 3.5でも実行できるようにすることが目標です。
型アノテーション追加という氏の提案は，PythonにHaskellの機能を部分的に導入する考えを以前から主張していたBob Ippolito氏と，動的型付けと静的型付けのメリットの両立を目指したPythonの実験版mypyの作者であるJukka Lehtosalo氏のアイデアをベースにしている。
提案の中心はmypyである。氏は実際にmypyについて，Pythonプログラムのコンパイル時やmypy Pythonインタプリタ上での実行時に型の妥当性チェックを実行可能な，lint的静的チェッカと考えてよいだろう，と述べている。その一方，Pythonの公式インタプリタで実行する場合には，型アノテーションによってプログラムの実行が影響を受けることはないため，実行時に型チェックのオーバーヘッドが発生しないことの保証が可能になる。これを可能にする上で重要な要件として，タイプアノテーションに使用するコードはPython 3のシンタックスに準拠していなければならない。これはmypyの特徴のひとつでもある。実際にmypyでは，関数に任意のメタデータを追加するPython 3の構文である関数アノテーションを，型シグネチャの指定に利用している。
mypyの基本的な構文の一例として，次のPythonの定義を，
def fib(n):
a, b = 0, 1
while a < n:
print(a)
a, b = b, a+b
mypyでは型シグネチャを指定して次のように変更できる。
def fib(n: int) -> None:
a, b = 0, 1
while a < n:
print(a)
a, b = b, a+b
型を指定のための適当な構文が存在しない部分では，Guido van Rossum氏が提案する次のようなコメントを使用する。
def word_count(input: List[str]) -> Dict[str, int]:
result = {} #type: Dict[str, int]
for line in input:
for word in line.split():
result[word] = result.get(word, 0) + 1
return result
これをすべて前提とすれば，REPの記述，受諾，実装はPython3.5の間に合うだろう，とGuidoは述べている。開発は，おもに２つの方向で進められることになりそうだ。
-
型アノテーションとしての使用を制限するため，関数アノテーション定義の再検討。
-
Guideが最小限にすると示唆している，Python 3.5に対する追加的な仕様の提供。
型チェッカが実際にPythonインタプリタに統合されることはありませんし，CPythonのリポジトリにチェックインされることもありません。stdlibに追加が必要なのはただひとつ，mypyのtyping.pyモジュールのコピーだけです。このモジュールは，引数の型を記述するために使用可能な，数十個の新しいクラス(と，いくつかのデコレータとその他ヘルパ)を定義しています。コードの型チェックを行うためには，mypyをダウンロードしてインストールし，別に実行する必要があります。
Guidoの提案に対しては，Python-ideasメールリストとredditの両方で関心が集まっている。議論には，何人かのコントリビュータによる肯定的な反応に加えて，関数アノテーションの型シグネチャアノテーションが制限されることや，型定義の手段としてコメントが利用されることへの懸念も提起されている。