python - Python 3への移行をどのように処理する予定ですか？

Question

Python 3が間もなくリリースされることを考えると、これはほとんどのPython開発者の頭に浮かぶテーマだと確信しています。私たちを正しい方向に進めるためのいくつかの質問：

1. 同時に維持するPython2とPython3のバージョンがありますか、それとも終了したらPython 3のバージョンがありますか？

   • すでに開始しましたか、またはすぐに開始する予定ですか？それとも、最終版が出て本格化するまで待つつもりですか？

Answer 1

これが Twisted の一般的な計画です。もともとこれをブログに書くつもりだったのですが、ポイントを獲得できるのに、なぜブログに書く必要があるのだろうと考えました。

1. 誰かが気にするまで待ってください。

   現在、誰も Python 3 を持っていません。少なくとも 1 人の実際のユーザーが現れて「Python 3.0 のサポートが必要です」と言ってくれるまでは、多くの労力を費やすつもりはありません。 3.0は光沢があります。

2. 依存関係が移行されるまで待ちます。

   Twisted のような大規模なシステムには、多くの依存関係があります。手始めに、私たちには以下が含まれます：

   • Zope インターフェイス
   • PyCrypto
   • PyOpenSSL
   • pywin32
   • PyGTK (残念なことに、この依存関係は現時点では非常に軽いですが、移行が始まる頃には、Twisted がより多くの GUI ツールを持っていることを願っています)
   • pyasn1
   • PyPAM
   • gmpy

   これらのプロジェクトの中には、独自の一連の依存関係があるため、それらも待つ必要があります。

3. 誰かが助けてくれるまで待ってください。

   慈善目的で Twisted に取り組んでいる人は 5 人います。私が「慈善目的で」と言ったのは、それが私の数であり、何ヶ月もコミットしていないからです。現在1000 を超える未解決のチケットがあり、それらのいくつかを実際に修正するのは良いことです — バグを修正し、機能を追加し、一般的に Twisted をそれ自体でより良い製品にします — 実質的に移植することに時間を費やす前に言語の新しいバージョン。

   これには、私たちがそれを行うためにお金を払ってくれるスポンサーも含まれる可能性がありますが、3.0 のサポートに関心があり、コミュニティを前進させる手助けをしたいというボランティアが殺到することを願っています.

4. グイドのアドバイスに従ってください。

   これは、互換性のない API を変更しないことを意味し、昨年 Guido が投稿した暫定的な開発ガイドラインに従います。それは、単体テストを行い、Twisted コードベースで2to3 変換ツールを実行することから始まります。

5. 2to3 ツールのバグを報告し、パッチを提出してください。

   実際に使用するようになると、今後、走行に多くの問題が発生することが予想さ2to3れます。現在 Twisted で実行すると非常に時間がかかります (最後に確認したのはかなり前のことです) Twisted リポジトリ内のいくつかのファイルを解析できないため、結果の出力はインポートされません。小さなプロジェクトからかなりの数の成功事例があり、ツールが実際に機能するようになる前に、ツールに多くの努力が必要になると思います。

   ただし、Python 開発チームはバグ レポートへの対応に非常に協力的であり、これらの問題に対する初期の対応は心強いものでした。したがって、これらの問題はすべて時間内に修正されることを期待しています。

6. 2.x との互換性を数年間維持します。

   現在、Twisted は python 2.3 から 2.5 をサポートしています。現在、2.6 のサポートに取り組んでいます (明らかに 3.0 より前に終了する必要があります!)。私たちの計画は、長期的にサポートされているUbuntuのバージョンに基づいて、サポートされているバージョンの Python を改訂することです。Python 2.5 を含むリリース 8.04 は、2013 年までサポートされます。 3.0 をサポートするようにしましたが、それを回避する方法を見つけられることを望んでいます (バージョン互換性のハックについては非常に独創的です)。

   そのため、少なくとも 2013 年までは Python 2.5 をサポートする予定です。2 年以内に、Ubuntu は別の長期サポート バージョンの Ubuntu をリリースする予定です。それらがまだ存在し、スケジュール通りに進めば、それは 10.04 になります。/usr/bin/python個人的には、ディストリビューションにパッケージ化された大量の Python ソフトウェアがあり、すべてを更新するには長い時間がかかるため、これは Python 2.x、おそらく python 2.8 とともに出荷されると推測しています。そのため、それから 5 年後の 2015 年には、2.x サポートの廃止を検討し始めることができます。

   この期間中、移行に関する Guido のアドバイスに従います。つまり、2.x コードベースで 2to3 を実行し、2.x コードベースを変更して両方のバージョンでテストをパスし続けるようにします。

   つまり、Python 3.x は、私の 35 歳の誕生日が終わるまで Twistedのソース言語にはならないということです。Python 3.x は、私の python 2.x コードのターゲット ランタイム (および一連のガイドラインと制限) になります。私は、今後 10 年ほどの間、Python 2.x でプログラムを作成する予定です。

それで、それが計画です。1 年かそこらで、笑えるほど保守的になることを願っています。3.x への移行はパイのように簡単で、誰もが迅速にアップグレードします。3to2他のことも起こる可能性があります: 2.x と 3.x ブランチが収束する、誰かが .直接処理して、変換プロセスを簡単にします。

しかし当面は、何年にもわたって、大規模なコードベースを維持している人々 (または、まだ移行されていない他のライブラリを使用したい新しいコードを書いている人々) が、まだ必要としていると想定しています。 Twisted の新機能とバグ修正。近いうちに、python 3 で Twisted を使用したい最先端のユーザーもいると思います。私は、それらすべての人々に、できるだけ長くポジティブな体験を提供したいと考えています。

Answer 2

Django プロジェクトはこのライブラリを使用して、Python 2とsixPython 3で同時に動作するコードベースを維持しています(ブログ投稿)。

sixこれは、インポートと関数をそれぞれの場所にインテリジェントにリダイレクトする互換性レイヤーを提供することで実現します (他の互換性のない変更を統合するだけでなく)。

明らかな利点:

• Python 2 と Python 3 に別々のブランチは必要ありません
• 2to3 などの変換ツールはありません。

Answer 3

2.6の主なアイデアは、3.0への移行パスを提供することです。したがってfrom __future__ import X、すべての機能が確定して3.0に移行できるようになるまで、一度に1つの機能をゆっくりと移行することができます。3.0の機能の多くは2.6にも流れ込むため、すべてを一度に移行する必要はなく、言語のギャップを徐々に小さくすることができます。

職場では、最初に2.5から2.6にアップグレードする予定です。次に、3.0機能を一度に1モジュールずつゆっくりと有効にし始めます。ある時点で、システムのサブパート全体が3.xの準備ができている可能性があります。

唯一の問題はライブラリです。ライブラリが移行されない場合は、古いライブラリでスタックします。しかし、私はその部分のためにやがて素晴らしい代替案を手に入れることができるとかなり確信しています。

Answer 4

図書館の著者として話す：

最終版がリリースされるのを待っています。私の信念は、ほとんどのPythonコミュニティと同様に、2.xが数週間または数か月間は引き続き主要なバージョンであるということです。洗練された3.xリリースをリリースするのに十分な時間です。

別々の2.xと3.xのブランチを維持します。2.xは2.4と下位互換性があるため、2.6/3.0では多くの凝った構文や新機能を使用できません。対照的に、3.xブランチは、これらの機能をすべて使用するため、ユーザーのエクスペリエンスが向上します。テストスイートは、2to3が機能するように変更され、両方のブランチで同じテストを維持します。

Answer 5

両方をサポート

私が取り組んでいるプロジェクトのために BeautifulSoup ライブラリを 3x に変換しようと試みたかったのですが、コードの 2 つの異なるブランチを維持するのがいかに面倒かがわかります。

これを処理する現在のモデルは次のとおりです。

1. 2x ブランチに変更を加える
2. 2対3で実行
3. 初めて変換が正しく行われることを祈ります
4. コードを実行する
5. 単体テストを実行して、すべてが機能することを確認します
6. 出力を 3x ブランチにコピーします

このモデルは機能しますが、私見は最悪です。変更/リリースごとに、次の手順を実行する必要があります ::sigh::. さらに、基本的にすべてのコードを 2x にターゲットしているため、開発者が py3k でのみサポートできる新機能で 3x ブランチを拡張することを思いとどまらせます。

解決策...プリプロセッサを使用する

Python 用の #define および #ifdef ディレクティブを備えた適切な C スタイルのプリプロセッサが見つからなかったので、作成しました。

これはpypreprocessor と呼ばれ、PYPI にあります。

基本的に、あなたがすることは次のとおりです。

1. インポート pypreprocessor
2. スクリプトが実行されている Python のバージョンを検出する
3. バージョンのプリプロセッサに「定義」を設定します（例：「python2」または「python3」）
4. コードがバージョン固有の「#ifdef python2」および「#ifdef python3」ディレクティブを振りかける
5. コードを実行する

それでおしまい。これで、2x と 3x の両方で動作します。プリプロセッサの実行による追加のパフォーマンス ヒットが心配な場合は、すべてのメタデータを取り除き、後処理されたソースをファイルに出力するモードもあります。

何よりも、2 対 3 の変換を 1 回行うだけで済みます。

これが実際の例です：

#!/usr/bin/env python
# py2and3.py

import sys
from pypreprocessor import pypreprocessor

#exclude
if sys.version[:3].split('.')[0] == '2':
    pypreprocessor.defines.append('python2')
if sys.version[:3].split('.')[0] == '3':
    pypreprocessor.defines.append('python3')

pypreprocessor.parse()
#endexclude
#ifdef python2
print('You are using Python 2x')
#ifdef python3
print('You are using python 3x')
#else
print('Python version not supported')
#endif

ターミナルでの結果は次のとおりです。

python py2and3.py
 >>>Python 2x を使用しています
 python3 py2and3.py
 >>>Python 3x を使用しています

ファイルに出力し、余分なメタデータを含まないクリーンなバージョン固有のソース ファイルを作成する場合は、次の 2 行を pypreprocessor.parse() ステートメントの前のどこかに追加します。

pypreprocessor.output = outputFileName.py
pypreprocessor.removeMeta = True

それで：

python py2and3.py

追加のメタデータを持たない、python 2x 固有の outputFileName.py というファイルを作成します。

python3 py2and3.py

追加のメタデータを持たない、python 3x 固有の outputFileName.py というファイルを作成します。

ドキュメントとその他の例については、GoogleCode の pypreprocessorを確認してください。

これがお役に立てば幸いです。私は Python でコードを書くのが大好きで、3x 領域へのサポートの進展をできるだけ早く見たいと思っています。私は言語が上達しないのを見るのが嫌いです。特に、3x バージョンでは多くの注目の WTF が解決され、構文が他の言語から移行するユーザーにとってより使いやすくなっています。

この時点でドキュメントは完成していますが、詳細ではありません。近いうちに、より広範な情報を wiki にアップしようと思います。

アップデート：

この問題を解決するために特別に pypreprocessor を設計しましたが、レクサーはコードが実行される前にすべてのコードの構文チェックを行うため、機能しません。

Python が実際の C プリプロセッサ ディレクティブをサポートしていれば、開発者は python2x と python3k の両方のコードを同じファイルに並べて書くことができますが、C プリプロセッサの評判が悪いため (言語キーワードを変更するためのマクロ置換の悪用)、私はしません。正当な C プリプロセッサのサポートが近いうちに Python に追加されることを確認してください。

Answer 6

Zope Toolkitは、Python3のサポートに向けてゆっくりと進んでいます。主にこれらのライブラリの多くが非常に複雑であるために遅くなります。

ほとんどのライブラリでは、2to3を使用しています。一部のライブラリは、単純であるか、ほとんどのコードがC拡張であるため、これなしで実行できます。関連パッケージであるzc.buildoutは、Python2および3をサポートするために2to3なしで同じコードを実行します。

TwistedやPyramidフレームワークなど、他の多くのライブラリやフレームワークがZTKに依存しているため、ZTKをPython3に移植します。

Answer 7

私のより複雑な2.xコードのいくつかは、2.5または2.6のままになります。私がよく使用するサードパーティライブラリの一部が3に更新されたら、すべての新しい開発のために3.0に移行します。