4 万行の Python コードの型チェックへのパス。 パート1

今日は、Dropbox が Python コードの型制御をどのように扱うかに関する資料の翻訳の最初の部分を紹介します。

Dropbox は Python で多くのことを記述しています。 これは、バックエンド サービスとデスクトップ クライアント アプリケーションの両方で非常に広く使用されている言語です。 Go、TypeScript、Rust もよく使用しますが、主な言語は Python です。 私たちの規模を考慮すると、数百万行の Python コードについて話しているのですが、そのようなコードの動的型付けは理解を不必要に複雑にし、労働生産性に深刻な影響を与え始めていることが判明しました。 この問題を軽減するために、mypy を使用してコードを静的型チェックに徐々に移行し始めました。 これはおそらく、Python の最も人気のあるスタンドアロン型チェック システムです。 Mypy はオープンソース プロジェクトであり、主な開発者は Dropbox で働いています。

Dropbox は、この規模で Python コードに静的型チェックを実装した最初の企業の XNUMX つです。 Mypy は最近、何千ものプロジェクトで使用されています。 彼らが言うように、このツールは何度も「実戦でテストされた」のです。 私たちは今の地位に到達するまで長い道のりを歩んできました。 その過程で、多くの失敗した事業や失敗した実験がありました。 この投稿では、私の研究プロジェクトの一環としての困難な始まりから、Python で作成する無数の開発者にとって型チェックと型ヒントが一般的になった現在に至るまで、Python の静的型チェックの歴史を説明します。 これらのメカニズムは現在、IDE やコード アナライザーなどの多くのツールでサポートされています。

→ 第二部を読む

なぜ型チェックが必要なのでしょうか?

動的型付けされた Python を使用したことがある場合は、なぜ最近静的型付けと mypy についてこれほど大騒ぎしているのかについて混乱するかもしれません。 あるいは、動的型付けのおかげで Python が好きなのに、起こっていることに単純に動揺しているのかもしれません。 静的型付けの価値の鍵は、ソリューションの規模です。プロジェクトが大規模になればなるほど、静的型付けへの傾きが高まり、最終的には静的型付けが本当に必要になります。

あるプロジェクトが数万行のサイズに達し、数人のプログラマーが作業していることが判明したとします。 私たちの経験に基づいて、同様のプロジェクトを見ると、そのコードを理解することが開発者の生産性を維持する鍵になると言えます。 型アノテーションがないと、たとえば、関数に渡す引数や関数が返すことができる型を把握することが困難になることがあります。 型アノテーションを使用しないと答えるのが難しい典型的な質問を次に示します。

• この関数は返せますか None?
• この議論はどうあるべきでしょうか? items?
• 属性タイプとは何ですか id: int それは...ですか、 str、それともカスタムタイプでしょうか？
• この引数はリストにする必要がありますか? タプルを渡すことは可能ですか?

次の型アノテーション付きコード スニペットを見て、同様の質問に答えてみると、これが最も単純なタスクであることがわかります。

class Resource:
    id: bytes
    ...
    def read_metadata(self, 
                      items: Sequence[str]) -> Dict[str, MetadataItem]:
        ...

• read_metadata 戻らない None、戻り値の型がそうでないため、 Optional[…].
• 引数 items は一連の行です。 ランダムに繰り返すことはできません。
• 属性 id バイト列です。

理想的な世界では、そのような微妙な点はすべて組み込みのドキュメント (docstring) で説明されることが期待されます。 しかし、経験上、そのようなドキュメントが作業対象のコード内で観察されないことが多いという事実を示す例が数多くあります。 たとえそのような文書がコード内に存在するとしても、その絶対的な正確性を信頼することはできません。 このドキュメントは曖昧で不正確で、誤解を招きやすい可能性があります。 大規模なチームや大規模なプロジェクトでは、この問題が非常に深刻になる可能性があります。

Python はプロジェクトの初期段階または中期段階では優れていますが、成功したプロジェクトや Python を使用する企業は、ある時点で「すべてを静的型付け言語で書き直す必要があるか?」という重大な問題に直面する可能性があります。

mypy のような型チェック システムは、開発者に型を記述するための形式言語を提供し、型宣言がプログラム実装と一致することを確認する (およびオプションで型宣言の存在を確認する) ことによって、上記の問題を解決します。 一般に、これらのシステムにより、注意深くチェックされた文書のようなものが自由に使えるようになったと言えます。

このようなシステムの使用には他にも利点があり、それらはすでに完全に自明ではありません。

• 型チェック システムは、いくつかの小さな (またはそれほど小さくない) エラーを検出できます。 典型的な例は、値の処理を忘れた場合です。 None またはその他の特別な条件。
• 多くの場合、型チェック システムはどのコードを変更する必要があるかについて非常に正確であるため、コードのリファクタリングが大幅に簡素化されます。 同時に、テストで 100% のコード カバレッジを期待する必要もありません (いずれにせよ、これは通常は不可能です)。 問題の原因を見つけるためにスタック トレースを深く調べる必要はありません。
• 大規模なプロジェクトであっても、mypy は多くの場合、完全な型チェックを数秒以内に実行できます。 また、テストの実行には通常、数十秒、場合によっては数分かかります。 型チェック システムはプログラマに即座にフィードバックを提供し、仕事をより速く実行できるようにします。 コード テストの結果をより速く取得するためだけに、実際のエンティティをモックやパッチに置き換える、壊れやすく保守が難しい単体テストを作成する必要はもうありません。

PyCharm や Visual Studio Code などの IDE とエディターは、型注釈の力を利用して、開発者にコード補完、エラーの強調表示、一般的に使用される言語構造のサポートを提供します。 これらはタイピングの利点のほんの一部です。 一部のプログラマにとって、これらすべてがタイピングを支持する主な議論です。 これは導入直後からメリットが得られるものです。 この型の使用例では、mypy のような別個の型チェック システムは必要ありませんが、mypy は型注釈とコードの一貫性を保つのに役立つことに注意してください。

マイピーの背景

mypy の歴史は、私が Dropbox に入社する数年前に英国のケンブリッジで始まりました。 私は博士課程の研究の一環として、静的型付け言語と動的言語の統合に携わってきました。 私は、Jeremy Siek と Walid Taha によるインクリメンタル タイピングに関する記事と、Typed Racket プロジェクトに触発されました。 私は、小さなスクリプトから数百万行からなるコードベースに至るまで、さまざまなプロジェクトで同じプログラミング言語を使用する方法を見つけようとしました。 同時に、どのような規模のプロジェクトでも大きな妥協をする必要がないようにしたいと考えました。 このすべての重要な部分は、型なしのプロトタイプ プロジェクトから、包括的にテストされた静的型付きの完成品に段階的に移行するというアイデアでした。 最近では、これらのアイデアはほとんどが当然のことと考えられていますが、2010 年当時、これは依然として活発に検討されていた問題でした。

私の元々の型チェックの仕事は Python を目的としたものではありませんでした。 代わりに、小さな「自家製」言語を使用しました アロー。 ここで説明している内容を理解するための例を次に示します (ここでは型注釈はオプションです)。

def Fib(n as Int) as Int
  if n <= 1
    return n
  else
    return Fib(n - 1) + Fib(n - 2)
  end
end

簡素化された母国語を使用することは、科学研究で使用される一般的なアプローチです。 これは、実験を迅速に行うことができるという理由だけでなく、研究に関係のないものは簡単に無視できるという事実からも当てはまります。 現実世界のプログラミング言語は、複雑な実装を伴う大規模な現象になる傾向があり、これが実験の速度を低下させます。 ただし、単純化された言語に基づく結果はどれも少し疑わしいように見えます。なぜなら、これらの結果を得る際に、研究者は言語の実際の使用に重要な考慮事項を犠牲にしていた可能性があるからです。

Alore 用の型チェッカーは非常に有望に見えましたが、Alore で書かれていないと言える実際のコードを試してテストしたいと思いました。 私にとって幸運なことに、Alore 言語は主に Python と同じ考え方に基づいていました。 Python の構文とセマンティクスで動作できるようにタイプチェッカーを作り直すのは簡単でした。 これにより、オープンソースの Python コードで型チェックを試すことができました。 さらに、Alore で書かれたコードを Python コードに変換するトランスパイラーを作成し、それをタイプチェッカー コードの変換に使用しました。 これで、Python のサブセット (その言語の一種) をサポートする Python で書かれた型チェック システムができました。 (Alore にとって意味のある特定のアーキテクチャ上の決定は、Python にはあまり適していませんでした。これは、mypy コードベースの一部で今でも顕著です。)

実際、この時点では、私の型システムでサポートされている言語は Python とは言えませんでした。これは、Python 3 の型注釈構文のいくつかの制限により、Python のバリアントでした。

Java と Python を組み合わせたもののように見えました。

int fib(int n):
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

当時の私のアイデアの XNUMX つは、型アノテーションを使用して、この種の Python を C またはおそらく JVM バイトコードにコンパイルすることでパフォーマンスを向上させることでした。 コンパイラのプロトタイプを作成する段階まで進みましたが、型チェック自体が非常に便利そうだったので、このアイデアは放棄しました。

私は最終的に、サンタクララで開催された PyCon 2013 でプロジェクトを発表することになりました。 私はこのことについて、Python の終身独裁者であるグイド・ヴァン・ロッサムとも話しました。 彼は私に、独自の構文をやめて標準の Python 3 構文に固執するよう説得しました。Python 3 は関数の注釈をサポートしているため、私の例は以下に示すように書き換えることができ、結果として通常の Python プログラムが得られます。

def fib(n: int) -> int:
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

いくつかの妥協をする必要がありました (まず、まさにこの理由から独自の構文を発明したことに注意したいと思います)。 特に、当時の言語の最新バージョンである Python 3.3 は、変数のアノテーションをサポートしていませんでした。 私はこのような注釈の構文設計についてのさまざまな可能性について電子メールで Guido と話し合いました。 変数には型コメントを使用することにしました。 これは意図した目的を果たしましたが、やや面倒でした (Python 3.6 ではより優れた構文が提供されました)。

products = []  # type: List[str]  # Eww

型コメントは、型注釈のサポートが組み込まれていない Python 2 をサポートするのにも役立ちました。

f fib(n):
    # type: (int) -> int
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

これら (およびその他) のトレードオフは実際には重要ではないことが判明しました。静的型付けの利点により、ユーザーは完璧とは言えない構文をすぐに忘れてしまいます。 型チェックされた Python コードでは特別な構文構造が使用されていないため、既存の Python ツールとコード処理プロセスは引き続き正常に動作し、開発者が新しいツールを習得するのがはるかに簡単になりました。

グイドさんも、卒業論文を完成させた後、Dropbox に入社するよう私を説得してくれました。 ここから、mypy ストーリーの最も興味深い部分が始まります。

継続するには...

親愛なる読者！ Python を使用している場合、この言語で開発するプロジェクトの規模について教えてください。

出所： habr.com