Python 3の開発と配布の課題

Question

Pythonで書かれた汎用エンドユーザーユーティリティを開発したとします。以前は、バージョン2.3以降のPythonに適したバージョンが1つしかありませんでした。 <！> quot;必要に応じてPythonをダウンロードしてから、このスクリプトを実行してください！<！> quot;ソース管理には、追跡するスクリプトのバージョンが1つしかありません（私はGitを使用しています）。

Python 3では、これは必ずしも真実ではありません。近い将来、Python 2.xに適したバージョンとPython 3.xに適したバージョンの2つの異なるバージョンを同時に開発する必要があります。開発の観点から、いくつかのオプションを考えることができます：

1. 同じブランチで2つの異なるスクリプトを維持し、両方を同時に改善します。
2. 2つの別個のブランチを維持し、開発が進むにつれて、共通の変更を前後にマージします。
3. スクリプトの1つのバージョンのみを維持し、スクリプトを1つのバージョンから別のバージョンに変換するパッチファイルをチェックインします。パッチがきれいに適用されなくなるほど十分な変更が行われたら、競合を解決し、新しいパッチを作成します。

私は現在、オプション3に傾いています。最初の2つはエラーが発生しやすい退屈な作業が多いためです。しかし、オプション3は面倒で、ソース管理システムがパッチを管理しているはずです。

配布パッケージの場合、選択可能なオプションは他にもあります：

1. Python 2に適したパッケージとPython 3に適したパッケージの2つの異なるダウンロードパッケージを提供します（ユーザーは、使用しているPythonのバージョンに応じて正しいパッケージをダウンロードする必要があります）。
2. 2つの異なるスクリプトを含む1つのダウンロードパッケージを提供します（その後、ユーザーは正しいパッケージを実行する必要があります）。
3. 2つのバージョン固有のスクリプトと、両方のPythonバージョンで実行できる小さなスタブローダーを備えた1つのダウンロードパッケージ。インストールされているPythonバージョンに対して正しいスクリプトを実行します。

私は現在、ここでオプション3に傾いていますが、そのようなスタブローダーの開発はまだ試みていません。

その他のアイデア？

Answer 1

編集：私の最初の答えは2009年の状態に基づいており、Python 2.6および3.0が現在のバージョンです。現在、Python 2.7および3.3には、他のオプションがあります。特に、Python 2およびPython 3に単一のコードベースを使用することが非常に可能になりました。

Python 2コードのPython 3への移植

をご覧ください。

元の答え：

公式の推奨事項言う：

  

既存のPython 2.5または2.6の移植用   Python 3.0のソースコード、最高   戦略は次のとおりです。

     

  

1. （前提条件:)優れたテストカバレッジから始めます。

  

2. Python 2.6への移植。これは平均的なポート以上の作業ではないはずです   Python 2.xからPython 2.（x + 1）へ。   すべてのテストに合格することを確認してください。

  

3. （2.6を使用しても：） -3コマンドラインスイッチをオンにします。これにより、   予定されている機能に関する警告   3.0で削除（または変更）されました。を実行します   スイートを再度テストし、コードを修正します   があるまで警告が表示されます   警告はありません。すべてのテスト   まだ合格。

  

4. ソースコードツリーで2to3ソースからソースへのトランスレーターを実行します。   （2to3-自動化されたPython 2 to 3を参照   詳細についてはコード変換   ツール））の結果を実行します   Python 3.0での翻訳。手動で   残っている問題を修正し、修正する   すべてのテストに再度合格するまで問題が発生します。

  

     

書くことはお勧めしません   下で変更なしで実行されるソースコード   Python 2.6と3.0の両方;あなた<！>＃8217; d   非常にゆがんだコーディングスタイルを使用し、   例えば印刷文を避け、   メタクラスなど。あなたがいる場合   必要なライブラリを維持する   Python 2.6とPythonの両方をサポート   3.0、最良のアプローチは2.6を編集して上記のステップ3を修正することです   ソースコードのバージョンと実行   ではなく、2to3トランスレーター   ソースの3.0バージョンの編集   コード。

理想的には、2.6と互換性があり、2to3を使用して3.0に変換できる単一のバージョンになります。実際には、この目標を完全に達成できない場合があります。そのため、3.0で動作させるには手動での修正が必要になる場合があります。

これらの変更は、オプション2のようにブランチで維持します。ただし、このブランチで3.0互換の最終バージョンを維持するのではなく、2to3の前に手動で変更を適用することを検討します翻訳し、この変更された2.6コードをブランチに配置します。この方法の利点は、このブランチと2.6トランクの違いがかなり小さく、2to3による変更ではなく、手動の変更のみで構成されることです。このようにして、別々のブランチの保守とマージがより簡単になり、2to3の将来の改善の恩恵を受けることができます。

代わりに、少し<！> quot; wait and see <！> quot;アプローチ。単一の2.6バージョンと2to3変換を使用できる範囲でのみ移植を進め、3.0バージョンが本当に必要になるまで残りの手動変更を延期します。おそらくこの時点で、手動での調整はもう必要ありません...

Answer 2

開発では、オプション3は面倒です。 2つのブランチを維持するのが最も簡単な方法ですが、その方法はVCSによって異なります。多くのDVCSは、別々のリポジトリ（マージを支援する共通の祖先を持つ）でより幸せになり、中央集中型VCSはおそらく2つのブランチで作業しやすくなります。オプション1は可能ですが、マージするものとエラーが発生しやすいIMOを見逃す可能性があります。

配布には、可能であればオプション3も使用します。とにかく3つのオプションはすべて有効であり、これらのモデルには時々バリエーションがあります。

Answer 3

私はこの道をまったくとらないと思います。どちらを見るにしても痛いです。実際、両方のバージョンを同時に維持することに強い商業的関心がない限り、これは利益よりも頭痛の種です。

現時点では、少なくとも数か月間、最大1年、2.xの開発を続ける方が理にかなっていると思います。いつかの時点で、2.xの最終的な安定バージョンを宣言し、3.x +の次のバージョンを開発する時期になります

たとえば、PyQt、matplotlib、numpy、その他いくつかの主要なフレームワークがそのようになるまで、3.xに切り替えません。また、ある時点で2.xのサポートを停止し、3.xの開発を開始するかどうかはあまり気にしません。すぐに3.xに切り替えることができることを知っているからです。

Answer 4

まず、Python 3.0に非常に近い2.6に移行します。 2.7を待つことさえできます。2.7はPython 3.0にさらに近くなります。

そして、2.6（または2.7）に移行したら、<！> quot; if PY3K：... else：... <！のようなスクリプトの1つのバージョンのみを保持することをお勧めします。 > quot;それが必須になるまれな場所で。もちろん、開発者が書くのが好きな種類のコードではありませんが、複数のスクリプト、ブランチ、パッチ、ディストリビューションの管理について心配する必要はありません。これは悪夢です。

選択するものは何でも、100％のコードカバレッジで徹底的なテストを行っていることを確認してください。

がんばって！

Answer 5

いずれの開発オプションを選択した場合でも、2つのバージョンが一致する出力を生成することを確認するための徹底した単体テストにより、潜在的な問題のほとんどを軽減できます。とはいえ、オプション2は私にとって最も自然なことです：ソースツリーから別のソースツリーに変更を適用することは、バージョン管理システムが設計されたタスク（ほとんど）です-提供するツールを活用してこれを簡単にするのはなぜですか

開発では、「聴衆を知る」ことなく言うのは困難です。 Power Pythonユーザーは、おそらくソフトウェアのコピーを2つダウンロードする必要がないことに感謝するでしょう。より一般的なユーザーベースの場合、おそらく「正常に動作する」はずです。