.. _typing-anti-pitch:

静的型チェックを避ける理由
==========================================================================================

:pep:`484` の言葉を借りれば:

    Python は動的型付け言語であり続けるべきであり、型ヒントを必須にするつもりはないし、慣習としてもそうするつもりはない。

Python の動的性が言語の強みであるという考えは、Python の型システムが漸進的であるという事実に反映されています。 詳細は :pep:`483` を参照してください。要するに、コードベースに静的型を追加するのは、望む範囲内でのみ可能であり、静的型チェッカーやその他のツールはこれに対応できるべきです。

また、「静的型チェック」にはさまざまな厳密さの度合いがあることも注目に値します。 一方では、型チェッカーがほとんど何もしないように設定することができます。 他方では、型チェックが大好きですが、型チェッカーが提供するすべての厳密なチェックを有効にしなければならない場合、Python をやめるでしょう。

とにかく、これを前提として、Python で静的型チェックを使用しない理由のリストを以下に示します。

* 単にそうしたくない。 Python はあなたに役立つツールです。 Python は大きなテントのような多パラダイム言語であり、一般的にあなたのニーズに最も適した方法で物事を行うことを許容します。

* 型注釈は可読性を向上させることもあれば、損なうこともあります。 型注釈は人間と機械の両方に役立ちますが、特に複雑な注釈や慣用表現の変更は機械にとっては有益ですが、人間にとってはそうではありません。 可読性は重要です。

* コストと利益の比率が十分でない。 静的型チェッカーを満足させるには、少なからず手間がかかります。 これが追加の信頼性に見合わない場合、静的型チェックを追加するべきではありません。

* コードベースが開発者の頭の中に収まる。 意見は分かれますが、ある程度の開発者数とコード行数に達すると、静的型チェックが大きな利益をもたらすと一般的に認識されています。 まだその段階に達していないと感じています。

* 高いテストカバレッジを維持している場合、それがあなたのニーズに対して十分な品質保証を提供するかもしれません（静的型チェックとテストは異なることを強制することを認識しています。静的型チェックは通常、ロジックを検証できず、テストはコードの不変性を証明できないことが多いです）。

* コードベースが古く、大規模で、何年も静的型チェックなしでうまく機能してきた。 Python の型システムは、静的型チェックの漸進的な導入を許容するように設計されていますが、大規模な既存のコードベースに型注釈を追加する総コストは高くなる可能性があります。

* アプリケーションが特に動的なフレームワークを使用しているか、ライブラリが十分に動的なことを行っているため、型チェックが開発者やユーザーに役立たない可能性があります。 アプリケーションフレームワークの移行にはコストがかかる可能性があります。 静的型チェッカーがより理解しやすいようにライブラリを再設計するか、静的型チェッカーの腕をひねるための巧妙な型注釈を見つけるには、多大な労力が必要です。

* コードベースが `Hyrum's Law <https://www.hyrumslaw.com/>`_ の影響を受けており、すべての可能な観察可能な動作に依存しています。 ユーザーに対して誤検知を避けるために、すべての型が a) 保守が難しい複雑な ``Protocol`` になるか、b) ``Any`` になるため、あまり意味がありません。 （一方で、静的型チェックは、ユーザーにどの動作に依存すべきかを伝えるための良い解決策となる可能性があります）

* 理論的には型チェックに反対していませんが、実際には Python 型チェッカーが嫌いです。 使用する慣用表現を十分に理解していないかもしれませんし、明示的な注釈に依存するのではなく、もっと推論してほしいかもしれませんし、遅すぎるかもしれませんし、エディターとの統合がうまくいかないかもしれませんし、設定が難しすぎるかもしれません。 いずれにせよ、プロジェクトにはうまくいきません。

* Python の型チェックは実際には十分に厳密ではなく、強力でもなく、表現力も十分ではありません。 Python 型チェッカーは実用性や限られたリソースのためにさまざまな決定を下しますが、これらの決定があなたにとって最適でない場合があります。 これは、型付き Python があなたにとって適切な言語ではないことを意味するかもしれませんし、望む特性を強制するための他の方法を見つける必要があるかもしれません。

型なしライブラリのメンテナーへのアドバイス
==========================================================================================

静的型を追加することがライブラリにとって適切な選択ではないと判断しました。 しかし、静的型チェックを使用するユーザーを支援したいと考えているかもしれませんし、熱心な貢献者がこれを手伝いたいと思っているかもしれません。

1 つのオプションは、そのような貢献者に、メインプロジェクトとは別に維持される :pep:`561` スタブのみのパッケージを公開するよう奨励することです。 これらのスタブを `typeshed <https://github.com/python/typeshed>`_ プロジェクトに提供することもできます。

スタブを維持する意思はあるが、インラインにしたくないし、コードを静的型チェックしたくない場合は、パッケージ内に型スタブを配布することでこれを実現できます。 詳細については :ref:`libraries` を参照してください。 型スタブの維持方法については :ref:`writing_stubs` を参照してください。

さらに多くのユーザーが静的型の追加を求めてきた場合、このドキュメントへのリンクを提供してください。 そして、気が変わった場合は、このドキュメントの他のガイドをいくつか確認し、`Python の型に関するディスカッション <https://github.com/python/typing/discussions>`_ で質問をしてください。