Python プロジェクト開発者 標準ライブラリの大規模なクリーンアップを行う提案 (PEP 594)。 明らかに時代遅れで高度に専門化された機能と、アーキテクチャ上の問題があり、すべてのプラットフォームに統合できないコンポーネントは、Python 標準ライブラリから削除するために提供されています。
たとえば、crypt (Windows では利用できないこと、およびハッシュ アルゴリズムの利用可能性がシステム ライブラリに依存する)、cgi (最適なアーキテクチャではない、リクエストごとに新しいプロセスを起動する必要がある)、imp などのモジュールを標準ライブラリから除外することが提案されています。 (importlib の使用を推奨)、pips (subprocess モジュールの使用を推奨)、nis (NSS、LDAP、または Kerberos/GSSAPI の使用を推奨)、spwd (アカウント データベースを直接操作することは推奨されません)。 モジュール binhex、uu、xdrlib も削除対象としてマークされています。
あいふん、
オーディオオペ、
かたまり
イメージグドゥル、
オサウディオデフ、
sndhdr、
スナウ
非同期、
非同期、
cgitb、
smtpd
nntplib、マックパス、
フォーマッタ、msilib、パーサー。
提案されている計画は、Python 3.8 で上記のモジュールを非推奨にし、Python 3.8 で警告を発行し、Python 3.10 で CPython リポジトリから削除することです。
パーサー モジュールは Python 3.9 リリースで非推奨になったため、バージョン 2.5 で削除される予定であり、macpath モジュールは 3.8 ブランチで削除される予定です。 メイン コードから削除された後、コードは別の Legacylib リポジトリに移動され、その運命はコミュニティ メンバーの関心によって決まります。 Python 3.9 ブランチは 2026 年までサポートされる予定であり、プロジェクトが外部の代替手段に移行するのに十分な時間が与えられます。
当初、ftplib、optparse、getopt、colorsys、fileinput、lib2to3、wave モジュールも削除が提案されましたが、これらのモジュールは広く普及しており、依然として関連性があるため、現時点では標準ライブラリの一部として残すことが決定されました。より高度な代替手段やオペレーティング システムの特定の機能へのバインディング。
Python プロジェクトは当初、「バッテリーを含む」アプローチを採用し、さまざまなアプリケーション向けの標準ライブラリで豊富な関数セットを提供していたことを思い出してください。 このアプローチの利点の XNUMX つは、Python プロジェクトの保守とプロジェクトで使用されるモジュールのセキュリティの監視が簡素化されることです。 モジュールの脆弱性は、多くの場合、それを使用するアプリケーションの脆弱性の原因となります。 標準ライブラリに関数が含まれていれば、メインプロジェクトの状態を制御するだけで十分です。 標準ライブラリを分割する場合、開発者はサードパーティ モジュールを使用する必要があり、それぞれの脆弱性を個別に監視する必要があります。 高度な断片化と多数の依存関係により、モジュール開発者のインフラストラクチャを侵害することによる攻撃の脅威があります。
一方、標準ライブラリの各追加モジュールを維持するには、Python 開発チームからのリソースが必要です。 ライブラリには多数の重複した冗長な関数が蓄積されており、それらを削除することでメンテナンス コストを削減できます。 カタログが進化するにつれて 追加パッケージのインストールとダウンロードのプロセスが簡素化されたため、外部モジュールの使用は組み込み関数と同じくらい一般的になりました。
標準モジュールのより機能的な外部代替物を使用する開発者がますます増えています。たとえば、xml の代わりに lxml モジュールを使用しています。 放棄されたモジュールを標準ライブラリから削除すると、コミュニティによって積極的に開発された代替モジュールの人気が高まります。 さらに、標準ライブラリを削減すると、基本ディストリビューションのサイズが削減されます。これは、ストレージ サイズが限られている組み込みプラットフォームで Python を使用する場合に重要です。
出所： オープンネット.ru