原文はこちら: Deprecations between Python 2.7 and 3.x
最近の python-dev の議論 で、Python 2.7 から Python 3.x の最新バージョンへ移行するときに遭遇する、いまの Python の段階的な廃止プロセスのポリシーに関する問題が浮き彫りになりました。この問題の結果として、Python ユーザが古いバージョンを調べずに Python 2.7 から 3.x の最新バージョンへ普通に移行するという事実を考慮して、開発チームはいまの段階的な廃止プロセスのポリシーを変更しました。
Python は後方互換性に対して強いコミットメントをもっています。互換性のガイドラインに準拠しない限りどんな変更も認められません。それは正しいプログラムが Python の新しいバージョンで実行できるというのが本質的なところです。しかし、このことは必ずしも可能だとは限りません。例えば、API が明確に分割されていて、他のものに置き換えられる必要がある場合です。そういった状況では、Python は段階的な廃止プロセスのポリシーに従い、1年間の移行期間を設けた上で、その削除される機能を公式に廃止します。移行期間中は、開発者が自分たちのコードを修正できるように廃止予定であることを表す警告を提示しなければなりません。Python の段階的な廃止プロセスのポリシーの詳細は PEP 5 に記載されています。その変更は新しい Python のリリースのみに行われるので、通常はリリース間で18ヶ月間の猶予があります。これは1つのリリースが標準の廃止期間であることを意味します。
このポリシーに対する例外の1つが Python 3 でした。Python 2 から Python 3 へのメジャーバージョンの変更は、特別に後方互換性を壊してでも、Python の開発者が既存ポリシーの範囲内ではシンプルに修正できない課題を是正する機会であることを目的としていました。例えば、デフォルトの文字列を Unicode にすることやリストの代わりにイテレータを返すことです。
多くの推計では、Python 3 への移行期間は5年かかると言われています。Python 2 と 3 の並行開発が行われることがありました。
Python 2.7 は Python 2 の最終リリースになります。そのメンテナンス期間は、かなり期間延長されることが合意されています。最終的には、Python の新バージョンへ移行したい開発者は Python 3 へ大きな変化を遂げる必要があります。
ここに1つ問題があります...
python-dev のスレッド で、ある特別な C API の関数 PyCObject_AsVoidPtr に注目が集まり、その関数は適切な警告もなく削除されました。さらにこれは遵守すべき段階的な廃止プロセスのポリシーを破るものでした。一体何が起こったのか？
この変更は、古い API (PyCObject) から新たに改善された (PyCapsule) への大きな移行の一部でした。この問題は PyCObject がデフォルトで、実際には Python 2.6 でのみ、その API が利用可能です。そして、Python 2.7 で廃止されました。Python 3.2 では、その API は存在せず新しい PyCapsule が使用されます。Python 2.7 リリース (2010年7月) から Python 3.2 リリース (2011年2月) への廃止期間は約7ヶ月間でした。この廃止期間は最低12ヶ月間よりもかなり短く、開発者が Python リリースの妥当な期間をサポートするのが難しくなります。
3.0 から 3.1 、そして 3.2 へ移行する廃止期間は大丈夫です。廃止期間をもつ Python 3.1 は2010年3月にリリースされて、3.x リリースの途中であり、ほぼ12ヶ月間の廃止期間が有効でした。しかし、実際には開発者にとってその廃止期間が有効ではありませんでした。開発者は Python 2.7 から直接、最新の 3.x バージョン、この場合は 3.2 へ移行して、結果としてこの問題に遭遇しました。これは決して python-dev で意図されたものではなく、PEP5 にも Python の並行バージョンについての記載がありません。どちらのバージョンも開発が行われている状況というのを考慮していませんでした。
PyCObject/PyCapsule API の非互換は明らかに問題でしたが、その一時的な回避策を講じることは不可能ではありません。しかし、python-dev で対処するには難しい問題であり、少なくとも今回の件がそうでした。全体的にこういったことが起こっているわけではありません。
PyCObject/PyCapsule の特殊な事例のために、この問題は既に存在しているので、対処するために行われたことは十分ではありません。 PyCObject を復活させることは、非互換な機能を追加することになるので、実際には選択肢になりません。しかし、つまらない方法ではあるけれど、どちらの API でも利用できるように適合するコードを書くことはできるというのが一般的な見解でした。実際、Python 3.1 では PyCObject API は PyCapsule API のラッパーとして実装されていました。Python 3.1 の実装がサードパーティ製品の用途に展開できると、それを必要とする者から提案がありました。さらに、開発者の移行を支援するドキュメントとその変更の背景にある理由を記述するために、変更に関する "遡及効果のある" PEP に記載する内容だと合意されました。
もう1つ一般的な注釈として、Python の開発チームは、いまこの問題に気付いて再発しないように取り組んでいます。Guido はその状況の レビューを投稿しました 。そして、Python 3 は当分の間、段階的な廃止プロセスを保守的なものにすべきだと提案しました。最低限、廃止予定の API は、開発者が Python 2.7 から移行できるように、実際に削除される前段階で長めに保持されます。
さらに間接的には、このスレッドで幅広いユーザに対して Python の変更を効果的且つタイムリーに伝える方法について課題が残りました。まさにこのブログが正面から取り組んでいる課題です。
まず第一に Python の開発者が全てにおいて、いつも正しいというわけではありません。開発者の生活に困難をもたらすという意味ではなく、単に開発期間中に発見されないものもあるということです。
次にその問題を修正することは、良いことよりも悪影響をもたらすので PyCObject の API は復活させません。復活させることで、その変更に関連する開発者を助ける可能性はありますが、全体として互換性の問題をより複雑にしてしまいます。その一方でこの問題に耐えて進歩しなければなりません。今回は教訓が得られたので、次に同じ間違いをすることはありません。
この問題が示したことは、Python の開発者はユーザからの意見を聞きたいということです。互換性はとても重要です。そして、新しいバージョンになるべく問題を発生させずに移行できるようにあらゆる努力が行われています。特に標準ライブラリの開発者は、妥当なレベルの努力で複数の Python バージョンをサポートすべきです。
最後に Python の開発者は 2.7 を放棄していません。新しい機能が取り込まれず、2.8 もリリースされませんが、それでも 2.7 を使用するユーザの視点を大事にしています。2.7 を使用するユーザの準備が整ったときに 3.x への移行を保証することは、Python コミュニティ全体にとって極めて重要なことです。
最近の python-dev の議論 で、Python 2.7 から Python 3.x の最新バージョンへ移行するときに遭遇する、いまの Python の段階的な廃止プロセスのポリシーに関する問題が浮き彫りになりました。この問題の結果として、Python ユーザが古いバージョンを調べずに Python 2.7 から 3.x の最新バージョンへ普通に移行するという事実を考慮して、開発チームはいまの段階的な廃止プロセスのポリシーを変更しました。
背景
Python は後方互換性に対して強いコミットメントをもっています。互換性のガイドラインに準拠しない限りどんな変更も認められません。それは正しいプログラムが Python の新しいバージョンで実行できるというのが本質的なところです。しかし、このことは必ずしも可能だとは限りません。例えば、API が明確に分割されていて、他のものに置き換えられる必要がある場合です。そういった状況では、Python は段階的な廃止プロセスのポリシーに従い、1年間の移行期間を設けた上で、その削除される機能を公式に廃止します。移行期間中は、開発者が自分たちのコードを修正できるように廃止予定であることを表す警告を提示しなければなりません。Python の段階的な廃止プロセスのポリシーの詳細は PEP 5 に記載されています。その変更は新しい Python のリリースのみに行われるので、通常はリリース間で18ヶ月間の猶予があります。これは1つのリリースが標準の廃止期間であることを意味します。
このポリシーに対する例外の1つが Python 3 でした。Python 2 から Python 3 へのメジャーバージョンの変更は、特別に後方互換性を壊してでも、Python の開発者が既存ポリシーの範囲内ではシンプルに修正できない課題を是正する機会であることを目的としていました。例えば、デフォルトの文字列を Unicode にすることやリストの代わりにイテレータを返すことです。
並行開発
多くの推計では、Python 3 への移行期間は5年かかると言われています。Python 2 と 3 の並行開発が行われることがありました。
Python 2.7 は Python 2 の最終リリースになります。そのメンテナンス期間は、かなり期間延長されることが合意されています。最終的には、Python の新バージョンへ移行したい開発者は Python 3 へ大きな変化を遂げる必要があります。
ここに1つ問題があります...
廃止機能にびっくり
python-dev のスレッド で、ある特別な C API の関数 PyCObject_AsVoidPtr に注目が集まり、その関数は適切な警告もなく削除されました。さらにこれは遵守すべき段階的な廃止プロセスのポリシーを破るものでした。一体何が起こったのか？
この変更は、古い API (PyCObject) から新たに改善された (PyCapsule) への大きな移行の一部でした。この問題は PyCObject がデフォルトで、実際には Python 2.6 でのみ、その API が利用可能です。そして、Python 2.7 で廃止されました。Python 3.2 では、その API は存在せず新しい PyCapsule が使用されます。Python 2.7 リリース (2010年7月) から Python 3.2 リリース (2011年2月) への廃止期間は約7ヶ月間でした。この廃止期間は最低12ヶ月間よりもかなり短く、開発者が Python リリースの妥当な期間をサポートするのが難しくなります。
3.0 から 3.1 、そして 3.2 へ移行する廃止期間は大丈夫です。廃止期間をもつ Python 3.1 は2010年3月にリリースされて、3.x リリースの途中であり、ほぼ12ヶ月間の廃止期間が有効でした。しかし、実際には開発者にとってその廃止期間が有効ではありませんでした。開発者は Python 2.7 から直接、最新の 3.x バージョン、この場合は 3.2 へ移行して、結果としてこの問題に遭遇しました。これは決して python-dev で意図されたものではなく、PEP5 にも Python の並行バージョンについての記載がありません。どちらのバージョンも開発が行われている状況というのを考慮していませんでした。
さて、どうしよう？
PyCObject/PyCapsule API の非互換は明らかに問題でしたが、その一時的な回避策を講じることは不可能ではありません。しかし、python-dev で対処するには難しい問題であり、少なくとも今回の件がそうでした。全体的にこういったことが起こっているわけではありません。
PyCObject/PyCapsule の特殊な事例のために、この問題は既に存在しているので、対処するために行われたことは十分ではありません。 PyCObject を復活させることは、非互換な機能を追加することになるので、実際には選択肢になりません。しかし、つまらない方法ではあるけれど、どちらの API でも利用できるように適合するコードを書くことはできるというのが一般的な見解でした。実際、Python 3.1 では PyCObject API は PyCapsule API のラッパーとして実装されていました。Python 3.1 の実装がサードパーティ製品の用途に展開できると、それを必要とする者から提案がありました。さらに、開発者の移行を支援するドキュメントとその変更の背景にある理由を記述するために、変更に関する "遡及効果のある" PEP に記載する内容だと合意されました。
もう1つ一般的な注釈として、Python の開発チームは、いまこの問題に気付いて再発しないように取り組んでいます。Guido はその状況の レビューを投稿しました 。そして、Python 3 は当分の間、段階的な廃止プロセスを保守的なものにすべきだと提案しました。最低限、廃止予定の API は、開発者が Python 2.7 から移行できるように、実際に削除される前段階で長めに保持されます。
さらに間接的には、このスレッドで幅広いユーザに対して Python の変更を効果的且つタイムリーに伝える方法について課題が残りました。まさにこのブログが正面から取り組んでいる課題です。
つまりは、どういうこと？
まず第一に Python の開発者が全てにおいて、いつも正しいというわけではありません。開発者の生活に困難をもたらすという意味ではなく、単に開発期間中に発見されないものもあるということです。
次にその問題を修正することは、良いことよりも悪影響をもたらすので PyCObject の API は復活させません。復活させることで、その変更に関連する開発者を助ける可能性はありますが、全体として互換性の問題をより複雑にしてしまいます。その一方でこの問題に耐えて進歩しなければなりません。今回は教訓が得られたので、次に同じ間違いをすることはありません。
この問題が示したことは、Python の開発者はユーザからの意見を聞きたいということです。互換性はとても重要です。そして、新しいバージョンになるべく問題を発生させずに移行できるようにあらゆる努力が行われています。特に標準ライブラリの開発者は、妥当なレベルの努力で複数の Python バージョンをサポートすべきです。
最後に Python の開発者は 2.7 を放棄していません。新しい機能が取り込まれず、2.8 もリリースされませんが、それでも 2.7 を使用するユーザの視点を大事にしています。2.7 を使用するユーザの準備が整ったときに 3.x への移行を保証することは、Python コミュニティ全体にとって極めて重要なことです。
0 件のコメント:
コメントを投稿