カンファレンスやPythonの発表リスト、さらには数え切れないほどのブログ記事や書籍で繰り広げられたニュース拡散の後、Python Software Foundationはついに、Python 2が2019年1月1日にサポート終了(EOL)に達することを正式発表する措置を講じた。
Python Foundationが声高に告げようとしているメッセージは、開発者はもはや待つことなく、可能な限り速やかにPython 3に移行すべきだ、というものである。
私たちは2020年1月1日を、Python 2の日没とすることに決定しました。従って、何らかのセキュリティ上の問題が発見された場合も、その日以降は修正を行いません。できる限り早く、Python 3にアップグレードする必要があります。
Python 3は、製作者であるGuido Van Rossum氏が言語を立ち上げてから9年後の2008年末にリリースされた。
発表当初からPython 3は、過去からの脱却を目的としていた。Python 2に影響した多くの欠陥を修正して前進するには、それが唯一の方法だったのだ。Python 2では、同じタスクを実現するための方法がいくつも蓄積されていたため、言語を再設計する上での指針のひとつは、ひとつのタスクを実行するための方法を明確にひとつだけにする、ということだった。
旧来の制約から開放されることで、将来的な言語の進化への道を開く一方で、後方互換性を失ったことは、Python 3の採用を著しく遅らせることになった。開発者がPython 3への移行を望まなかった理由としては、1) 少なくとも最初のリリースからバージョン3.3までの数年間は、Python 2よりパフォーマンスが劣っていた、2) サードパーティ製のツールやPythonライブラリが当初、Python 3をサポートしていなかった(ある種のジレンマ状態)、3) 重点を置いた機能に対して、当初は開発者が関心を持っていなかった、などがあった。そのような状況にも関わらず、この言語は長年にわたって大きく成長し、ジェネレータやコルーチン、async/await、concurrent futures、itertoolsなどの高度な構造が含まれるようになった。しばらくの間、ソース互換性のない２つのバージョンの言語を同時に処理する方法に関して、ある程度の混乱があったことは事実である。しかしながら、Python 2コードのPython 3への移植作業に関する理解が進んだことにより、caniusepython3やFuturize、Modernize、pylintといった優れたツールが登場した。
これらがすべて、多くの組織において、より現代的で表現力豊かな言語への移行が無期限に延期される事態に一役買うことになったのだ。これまではそうだったが、今回、Python Foundationが警告を発したことにより、彼らは自力で問題を解決することになり、サポートを受ける唯一の手段は有償の延長サポートのみになる。
ニュースに対する反応は複雑だった。その一方で、多くの開発者たちが、Python 3へのコードの移植が簡単であることを強調している。
Python 2から3(少なくとも3.3あたりまで)への移行は、私が今まで行った中で最も簡単なもののひとつでした。便利なライブラリ("6")があるので、ほとんどすべての場合において、バージョン2と3で互換性のあるコードを書くことが可能です。
さらに踏み込んで、Python 3への移行の準備は、ユニットテストの構成を維持し、依存関係を最新の状態に保つなど、優れたエンジニアリングプラクティスを適用すれば十分だ、という意見もある。
これまでPy2からPy3へのアプリ更新を優先項目としていなかったならば、あなたのショップの優先順位は間違っていると思います。Py2/3に限ったことではありません。依存性の腐敗は、技術的負債の最悪の形態のひとつなのです。多くの場合において、CIの損傷、セキュリティスキャンの損傷、その他多くのプロセスの損傷として顕在化し、将来的にはチームをますます窮地に追い込むことになります。
DjangoやFlaskなどをベースとしたほとんどのプロジェクトで、移植は容易あるいは実施可能である、という意見がある一方で、C言語拡張の非互換性や置き換え不能な依存関係など、何らかの障害に移植作業がヒットするシナリオもまだ数多く存在する。コンピューターグラフィックスや視覚効果、科学計算の世界では、このようなケースが少なくないのだ。
Nuke、Houdini、Mayaといったメジャーなアプリケーションや、ライブラリ、APIの内部でPythonランタイムが使用されているため、ユーザやスタジオはそれによって足止めされることになります。これらはいずれも、Python 3で実行するバージョンをまだリリースしていません。[...] また私は、おそらく多くの人が耳にしたことのあるスタジオのいくつかで働いているのですが、どのスタジオも、自分たちのコードの大半をカバーするようなユニットテストを持っていません。アーキテクチャや完全性よりもニーズへの対応が重視される社内アーティストを支援するツールに重点が置かれているのです。
科学関係のスタックは、その全体が"できの悪いC言語拡張"の集まりです。Python/C開発者が比較的少なく、予算が限られていることもその理由のひとつです。
Python 2.7 EOLをコミュニティに浸透させるために多くの努力が払われたにも関わらず、Python 2の資料に移行のヒントが提供されていない、と不満を言う開発者もいる。
これとは対照的に、PostgreSQLのWebサイトでは、古いドキュメントをブラウジングしていることに気付きます(Googleの提供しているリンクが古いため)。例えば、https：//www.postgresql.org/docs/9.2/tutorial-window.htmlを参照してみてください。
ここで再び、初期におけるPython 2からPython 3への移行の対応が"不十分"であった点に注目が集まることになる。
Pythonのアプローチを、"ユーザ空間を損なわない"健全なアプローチと対比する開発者もいる。そのようなアプローチは、言語と、それらを使用して記述されたシステムの寿命を長くする。
手元に70年代からのFORTRANコードが大量にあるのですが、最新かつ最高のFORTRANコンパイラでも正常に動作します(リファクタリング作業を支援する非推奨の警告を除けば)。80年代のC/C++も同じです。
最後に注意すべき点は、Python Foundationの発表は、他の組織がPython 2.7をメンテナンスして、最新の状態を保つための負担を引き受ける可能性を排除するものではない、ということだ。例えば、RHEL 7はPython 2.7をベースとしているが、2024年6月までのセキュリティ/メンテナンスサポートを保証し{ている。Google App Engineや他のエンタープライズサービスプロバイダについても、同じことが言える。