この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
2020年1月1日に、Python 2.7のオフィシャルなサポートが終了する。これに関連して、PyCon JP 2019ではセバスティアン・ヴィトヴスキ氏による「It’s 2019 and I’m still using Python 2. Should I be worried?」(2019年、まだPython 2を使っているんだ。心配する必要あるかな?)というトークセッションが開かれた。
本稿では、その内容をかいつまんでご紹介していこう。セッションの資料はこちらから参照できる。
ちなみに、本稿を掲載している@IT Deep Insiderフォーラム全体の指針としてはPython 3の使用を前提としており、セバスティアン・ヴィトヴスキ氏の意見と同様に、このタイミングでPython 2から3に移行するのを推奨する。
ヴィトヴスキ氏からは、Python 2がまだ使われている理由としては以下の3つが挙げられた。
つまり、「Python 2のコードをPython 3に書き直しても会社にはお金は入ってこない」し、マネジャーは「リファクタリングに時間を費やしたり、動いているコードを書き直したりすること」に首を縦には振らないだろう。さらに「テストやドキュメントもなく、担当者がいなくなってからずいぶんとたつPython 2のコード」をPython 3へ移行するのは非常に難しい。こうしたことから、Python 2からPython 3への移行が進んでいないと彼はいう。
その一方で、Python 3への移行にはメリットもある。以下はヴィトヴスキ氏によるPython 3へ移行することのメリットだ。
まず、Python 2のオフィシャルなサポートは近いうちに終了するので、Python 3に移行することで、オフィシャルなサポートが終了したバージョンのPythonを使い続けずに済む。そして、Python 3の方がPython 2よりも高速であり、便利な新機能も実装が続けられている。そして、現在では多くのフレームワークやライブラリがPython 3へと移行を済ませている。
どれほどのフレームワークやライブラリがPython 3へ移行しているかはSunsetting Python 2 support(Moving to require Python 3)で確認できる。
こうしたことから、「Now is the best time to migrate!」(今が移行にはベストのタイミングだ!)と彼はいう。そのタイミングはもっと前からあったはずだが、なぜ今なのだろうか。その理由としてヴィトヴスキ氏は以下を挙げた。
では、Python 2のサポートが終了したときに、どんなことができるだろう。上から順に、手間がかからない方法を列挙する。
その中で最も一般的な選択肢となるのが「Python 3に移行する」だ。ただし、その作業量は多くなる。
Python 2のコードをPython 3へと移行するには大きく分けて次の2つの方法が考えられる。
セッションでは、それぞれの方法の作業の進め方や、それぞれのメリット/デメリットなどについても触れているので、興味のある方は動画をご覧いただきたい。
前者は既存のコードをPython 2とPython 3の両方で動作するように書き換えていく(もちろん、そのためにはテストが必要になる)。移行が終わるまではPython 2を実行環境として使用し、移行できた時点でインタプリターをPython 3に切り替える(可能なら、その後、Python 2は削除する)。
この方法では、現在動いているプロダクションコードを反復的に少しずつ置き換えていくことになる。その間に(両方のバージョンをサポートしたコードを書くことで)機能を追加することも可能だ。現在動いているアプリケーションを大々的に停止させる必要がないことはメリットといえる。
後者の方法では、移行が完了するまではPython 2バージョンを動かしながら、別途、Python 3で動くコードにアプリケーションを書き直していく。Python 2のことを考慮しなくてよいので、作業量は前者よりも少なくなると思われる。そして、Python 3バージョンが完成した時点でPython 2バージョンからPython 3バージョンへ切り替える。このときにはテストの不備などで失敗する可能性もあるし、前者の方法とは異なり、開発時に同じ機能を両者に追加するのも難しい(両方のコードベースにそれぞれにコードを追加する必要があるだろう)。
他の選択肢についても簡単に触れておこう。
「Dockerを使ってアプリケーションとその実行環境をコンテナ化する」というのは、既に動作しているアプリケーションとその実行環境をコンテナ化することで、現状のプログラムをそのままの形で使い続けられるようにすることだ。Python自身やフレームワークなどに脆弱性があったときには、それを解決できるわけではないが、組織内部で使用するアプリケーションには適した対処といえる。この方法を取るのであれば、2020年を待たずに今すぐやることも勧められていた。
「Pythonインタプリターを変更する」というのは、Python Software Foundation(PSF)がオフィシャルに開発/サポートを行っている、いわゆる「CPython」ではないPythonを使うようにするということだ。「2020年1月1日にサポートが終了するPython」とはこのCPythonのことであり、これ以外にも配布されているPython処理系はある。
そうした代替のPythonインタプリターとしては、例えばPyPy、Intelが配布している「Intel Distribution for Python*」、Red Hat Enterprise Linux 7(RHEL 7)などが候補となる。
「自分でCPython 2をメンテナンスする」というのは、CPython 2のレポジトリをフォークして、自分でCPython 2をビルドして、それを自身のプロダクトで使うという意味だ。日々の運用の中で脆弱性が発見されたら、自分でパッチを当て(て、ビルドをして、……という手間暇をかけ)なければならない。聞くだけでも、これは避けたいと思う選択肢ではある。
最後がPython 3(または別の言語)を使って「ゼロから書き直す」となる。作業量はもちろん多くなるし、これが意味を持つのはPython 2バージョンのアプリケーションをプロトタイプとして捉えられるときかもしれない。いずれにせよ、設計もゼロから行うことになるだろう。
では、移行すると決まったら、どうすればよいだろう。ヴィトヴスキ氏によると次の「4つ」が必要になる。これらの要素はPython 3への移行に限らず、Python 2.7からPyPyや他のPython 2.7インタプリターへの移行においても同様とのことだ。
テストコード(とドキュメント)が欠如していることで、Python 3への移行が進まないプロジェクトは数多い。十分な量のテストコードがなければ、自分たちが正しいことをしていることを確信できない以上、そうなるのは当然だ。そうしたプロジェクトをPython 3に移行するには、テストコードを書くところから始める必要がある。その場合、テストコードをPython 2とPython 3の両者で実行できる必要がある。
Copyright© Digital Advantage Corp. All Rights Reserved.