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

本日、Dropbox が数百万行の Python コードの型制御をどのように整理したかに関する資料の翻訳の第 XNUMX 部を公開します。

→ 最初の部分を読む

公式タイプのサポート (PEP 484)

私たちは、Hack Week 2014 中に、Dropbox 上で mypy を使った最初の本格的な実験を行いました。Hack Week は、Dropbox が主催する XNUMX 週間のイベントです。 この間、従業員は何にでも取り組むことができます。 Dropbox の最も有名なテクノロジー プロジェクトのいくつかは、このようなイベントから始まりました。 この実験の結果、このプロジェクトはまだ広く使用する準備ができていませんが、mypy は有望であると結論付けました。

当時、Python のタイプヒンティングシステムを標準化するというアイデアが浮上していました。 先ほども述べたように、Python 3.0 以降、関数に型アノテーションを使用できるようになりましたが、これらは単なる任意の式であり、構文やセマンティクスが定義されていませんでした。 プログラムの実行中、これらの注釈はほとんどの場合、無視されます。 Hack Week の後、私たちはセマンティックの標準化に取り組み始めました。 この作品が出現につながった PEP484 (Guido van Rossum、Lukasz Langa、そして私はこの文書に協力しました)。

私たちの動機は XNUMX つの側面から見ることができます。 まず、Python エコシステム全体がタイプ ヒントの使用に共通のアプローチを採用できることを期待しました (タイプ ヒントは、Python で「型アノテーション」の類似物として使用される用語です)。 起こり得るリスクを考慮すると、相互に互換性のない多くのアプローチを使用するよりも、この方が良いでしょう。 次に、Python コミュニティの多くの人々と型アノテーションの仕組みについてオープンに議論したいと考えました。 この願望の一部は、一般大衆の Python プログラマーの目に、言語の基本的な考え方から「背教者」のように見られたくないという事実によって決まりました。 「ダックタイピング」で知られる動的型付け言語です。 コミュニティでは、当初、静的型付けのアイデアに対してやや疑わしい態度が生じざるを得ませんでした。 しかし、静的型付けが必須ではないことが明らかになり (そして静的型付けが本当に便利であると人々が認識した後)、その感情は最終的に消え去りました。

最終的に採用されたタイプヒント構文は、当時 mypy でサポートされていたものと非常に似ていました。 PEP 484 は 3.5 年に Python 2015 とともにリリースされました。 Python は動的型付け言語ではなくなりました。 私はこのイベントを Python の歴史におけるマイルストーンとして考えたいと思います。

移行の開始

2015 年末、mypy に取り組むために Dropbox で XNUMX 人のチームが設立されました。 グイド・ファン・ロッサム、グレッグ・プライス、デイビッド・フィッシャーも含まれていた。 その瞬間から、状況は非常に急速に発展し始めました。 mypy の成長に対する最初の障害はパフォーマンスでした。 上でほのめかしたように、プロジェクトの初期には mypy 実装を C に変換することを考えていましたが、その考えは今のところリストから除外されました。 システムの起動に CPython インタープリターが使用されたという事実に行き詰まっていますが、これは mypy などのツールにとって十分な速度ではありません。 (JIT コンパイラーを使用した Python の代替実装である PyPy プロジェクトも役に立ちませんでした。)

幸いなことに、ここでいくつかのアルゴリズムの改善が役に立ちました。 最初の強力な「アクセラレータ」は、増分チェックの実装でした。 この改善の背後にあるアイデアは単純です。前回の mypy の実行以降、すべてのモジュールの依存関係が変更されていない場合、前回のセッション中にキャッシュされたデータを使用して依存関係を操作できます。 変更されたファイルと、それらに依存するファイルに対して型チェックを実行するだけで済みました。 Mypy はさらにもう少し進めました。モジュールの外部インターフェイスが変更されない場合、mypy は、このモジュールをインポートする他のモジュールを再チェックする必要がないとみなしました。

増分チェックは、大量の既存のコードに注釈を付けるときに非常に役立ちました。 実際、このプロセスには通常、注釈が徐々にコードに追加され、徐々に改善されるため、mypy の反復実行が何度も含まれます。 mypy の最初の実行は、多くの依存関係をチェックする必要があったため、依然として非常に遅かったです。 そこで、この状況を改善するために、リモート キャッシュ メカニズムを実装しました。 mypy は、ローカル キャッシュがおそらく古いことを検出すると、コードベース全体の現在のキャッシュ スナップショットを集中リポジトリからダウンロードします。 次に、そのスナップショットを使用して増分チェックを実行します。 これは、mypy のパフォーマンス向上への取り組みにおける大きな前進です。

この時期は、Dropbox の型チェック システムが急速かつ自然に採用された時期でした。 2016 年末までに、型アノテーションを含む Python コードがすでに約 420000 行ありました。 多くのユーザーが型チェックに熱心になっています。 より多くの開発チームが Dropbox mypy を使用しました。

その時はすべてが順調に見えましたが、まだやるべきことがたくさんありました。 私たちは、プロジェクトの問題領域を特定し、最初に解決する必要がある問題を理解するために、定期的な社内ユーザー調査の実施を開始しました (この慣行は現在も社内で使用されています)。 明らかになったように、最も重要なのは XNUMX つのタスクでした。 XNUMX つ目は、型に関するコード カバレッジを増やす必要があるということで、XNUMX つ目は、mypy がより高速に動作する必要があるということでした。 mypy を高速化し、それを会社のプロジェクトに導入するという私たちの取り組みがまだ終わっていないことは明らかでした。 私たちは、これら XNUMX つの課題の重要性を十分に認識し、その解決策に取り組みました。

さらなるパフォーマンスを！

増分チェックにより mypy は高速になりましたが、それでも十分な速度ではありませんでした。 多くの増分チェックは約 XNUMX 分間続きました。 その理由は循環的な輸入だった。 Python で書かれた大規模なコードベースを扱ったことのある人なら、これはおそらく驚くことではないでしょう。 数百のモジュールのセットがあり、それぞれが他のモジュールをすべて間接的にインポートしていました。 インポート ループ内のファイルが変更された場合、mypy はそのループ内のすべてのファイルを処理する必要があり、多くの場合、そのループからモジュールをインポートするモジュールも処理する必要がありました。 そのようなサイクルの XNUMX つは、Dropbox で多くの問題を引き起こした悪名高い「依存症のもつれ」でした。 かつてこの構造には数百のモジュールが含まれており、直接的または間接的に多くのテストがインポートされると同時に、製品コードでも使用されました。

循環依存関係を解明することを検討しましたが、それを行うためのリソースがありませんでした。 馴染みのないコードが多すぎました。 その結果、私たちは別のアプローチを思いつきました。 私たちは、「依存関係のもつれ」があっても mypy を高速に実行できるようにすることにしました。 mypy デーモンを使用してこの目標を達成しました。 デーモンは、XNUMX つの興味深い機能を実装するサーバー プロセスです。 まず、コードベース全体に関する情報をメモリ内に保持します。 これは、mypy を実行するたびに、インポートされた何千もの依存関係に関連するキャッシュされたデータをロードする必要がないことを意味します。 第二に、彼は小さな構造単位のレベルで、機能と他のエンティティ間の依存関係を注意深く分析します。 たとえば、関数の場合、 foo 関数を呼び出す bar、依存性があります foo から bar。 ファイルが変更されると、デーモンはまず、変更されたファイルのみを単独で処理します。 次に、関数シグネチャの変更など、そのファイルに対する外部から見える変更を探します。 デーモンは、変更された関数を実際に使用する関数を再確認するためにのみ、インポートに関する詳細情報を使用します。 通常、このアプローチでは、チェックする関数はほとんどありません。

mypy の元の実装は一度に XNUMX つのファイルを処理することに重点を置いていたため、これらすべてを実装するのは困難でした。 私たちは多くのエッジな状況に対処する必要があり、コード内で何かが変更された場合には繰り返しチェックする必要がありました。 たとえば、これはクラスに新しい基本クラスが割り当てられたときに発生します。 必要なことを実行した後、ほとんどの増分チェックの実行時間を数秒に短縮することができました。 私たちにとっては大きな勝利のように思えました。

さらにパフォーマンスアップ！

上で説明したリモート キャッシュと併せて、mypy デーモンは、プログラマが少数のファイルに変更を加えて型チェックを頻繁に実行するときに発生する問題をほぼ完全に解決しました。 ただし、最悪の使用例におけるシステム パフォーマンスは依然として最適とは程遠いものでした。 mypy をクリーンに起動するには 15 分以上かかる場合があります。 そしてそれは私たちが望んでいたものをはるかに超えていました。 プログラマーが新しいコードを書き、既存のコードに注釈を追加し続けるため、状況は毎週悪化しました。 ユーザーは依然としてさらなるパフォーマンスを求めていましたが、私たちは彼らの要望に応えることができてうれしく思いました。

私たちは、mypy の初期のアイデアの 10 つに戻ることにしました。 つまり、Python コードを C コードに変換します。 Cython (Python で書かれたコードを C コードに変換できるシステム) を使った実験では、目に見える高速化が得られなかったため、独自のコンパイラを作成するというアイデアを復活させることにしました。 mypy コードベース (Python で書かれた) には必要な型アノテーションがすべてすでに含まれているため、これらのアノテーションを使用してシステムを高速化することは価値があると思われました。 このアイデアをテストするために、すぐにプロトタイプを作成しました。 さまざまなマイクロベンチマークでパフォーマンスが XNUMX 倍以上向上していることがわかりました。 私たちのアイデアは、Cython を使用して Python モジュールを C モジュールにコンパイルし、型注釈を実行時の型チェックに変えることでした (通常、型注釈は実行時には無視され、型チェッカーによってのみ使用されます)。 実際、私たちは mypy の実装を Python から、静的に型付けされて作成された、Python とまったく同じように見える (そしてほとんどの場合動作する) 言語に変換することを計画していました。 (この種の言語を越えた移行は、mypy プロジェクトの伝統のようなものになっています。mypy の元の実装は Alore で書かれ、その後 Java と Python の構文ハイブリッドが存在しました)。

CPython 拡張 API に焦点を当てることが、プロジェクト管理機能を失わないための鍵でした。 mypy に必要な仮想マシンやライブラリを実装する必要はありませんでした。 さらに、Python エコシステム全体が引き続き利用可能となり、すべてのツール (pytest など) が利用可能になります。 これは、開発中に解釈された Python コードを使用し続けることができることを意味します。これにより、コードがコンパイルされるのを待つのではなく、コードに変更を加えてテストするための非常に高速なスキームを使用して作業を続けることができます。 私たちは XNUMX つの椅子に座って、いわばうまくやっているように見え、それが気に入りました。

私たちが mypyc と名付けたコンパイラー (型解析のフロントエンドとして mypy を使用するため) は、非常に成功したプロジェクトであることが判明しました。 全体として、キャッシュを使用せずに頻繁に mypy を起動する場合、約 4 倍の高速化を達成しました。 Michael Sullivan、Ivan Levkivsky、Hugh Khan、そして私からなる小規模なチームが、mypyc プロジェクトの中核を約 4 暦月で開発しました。 この作業量は、たとえば C++ や Go で mypy を書き直すのに必要な作業量よりもはるかに野心的ではありませんでした。 また、プロジェクトを別の言語で書き直す場合に比べて、プロジェクトに加える変更ははるかに少なくて済みました。 また、Dropbox の他のプログラマーが mypyc を使用してコードをコンパイルし、高速化できるレベルに mypyc を引き上げることができればと考えていました。

このレベルのパフォーマンスを達成するには、いくつかの興味深いエンジニアリング ソリューションを適用する必要がありました。 たとえば、コンパイラは、高速で低レベルの C コンストラクトを使用することで、多くの操作を高速化できます。たとえば、コンパイルされた関数への呼び出しは、C 関数への呼び出しに変換されます。 そして、そのような呼び出しは、解釈された関数を呼び出すよりもはるかに高速です。 辞書検索などの一部の操作は、依然として通常の CPython C-API 呼び出しの使用に制限されていましたが、コンパイル後はわずかに高速化されるだけでした。 解釈によってシステムに生じた追加の負荷を取り除くことはできましたが、この場合、パフォーマンスの向上はわずかしかありませんでした。

最も一般的な「遅い」操作を特定するために、コード プロファイリングを実行しました。 このデータを用意して、mypyc を微調整してこれらの操作用に高速な C コードを生成するか、対応する Python コードを書き直して高速な操作を使用しようとしました (場合によっては、そのための十分な単純な解決策がなかっただけです)。またはその他の問題）。 Python コードを書き直す方が、コンパイラーに同じ変換を自動的に実行させるよりも簡単に問題を解決できることが多くの場合証明されています。 長期的には、これらの変換の多くを自動化したいと考えていましたが、当時はできるだけ少ない労力で mypy を高速化することに重点を置いていました。 そして、この目標に向かって進んでいる私たちは、いくつかの角を切り落としました。

継続するには...

親愛なる読者！ mypy プロジェクトを知ったとき、どのような印象を受けましたか?

出所： habr.com