本番開発の取り組みのために、どのバージョンのPython（2.4、2.5、2.6、3.0）を標準化していますか（そしてその理由）。

Question

私たちのグループでは、主に検索エンジンアーキテクチャとコンテンツ統合作業を行っており、そのコードベースのほとんどはPythonにあります。ビルドツールとPythonモジュールの依存関係はすべてソース管理にあるため、os / platformに関係なく使用できるようにチェックアウトし、環境をロードできます。これは、アプローチ virtualenv が使用します。

長年にわたり、使用している商用製品の1つがPython 2.3に依存しているため、Python 2.3と互換性のあるコードベースを維持しています。 2004年に2.3がリリースされて以来、新しいツールとライブラリには新しいバージョンのPythonが必要になるため、長年にわたってこれがますます多くの問題を引き起こしています。

最近、ビルド環境を商用製品の環境への依存から切り離し、必要なPython（またはJava）の任意のバージョンを使用できます。以前のバージョンと後方互換性のあるPythonの最新バージョンとしてPython 2.6で標準化してから約1か月ほどでした。

Python 3.0は（今のところ）オプションではありません。ビルドツールと統合ツールを再び正常に動作させるには、コードベースの多くを移行する必要があるからです。

Python 2.6の多くの新機能、特に改善されたモジュールやクラスデコレータなどが気に入っていますが、依存している多くのモジュールにより、Python 2.6インタプリタはさまざまな減価償却の警告を発します。 EC2クラウドクラスターノードの管理に興味がある別のツール、 Supervisor は機能しませんPython 2.6で正しく。

今、実稼働環境ツールの開発でPython 2.6を使用する代わりに、Python 2.5で標準化する必要があるかどうか疑問に思っています。私たちが望む/必要とするツールのほとんどは、Python 2.5で正しく動作するようです。 Python 2.6の機能またはモジュールに多くの依存関係がある前に、これを整理しようとしています。

どうもありがとう！

-マイケル

Answer 1

廃止の警告だけで2.6を放棄しません。それらは時間とともに消えます。 （少なくともPythonインタープリターに -W ignore オプションを使用して、それらが印刷されないようにすることができます）しかし、実際に使用する必要があるモジュールがPython 2.6で機能しない場合は、 2.5にとどまる正当な理由。 Python 2.5は現在広く使用されており、おそらく（2.3がどれだけ続いたかを考慮して！）長い間続くので、2.5を使用しても、しばらくアップグレードすることはありません。

すべての開発作業にPython 2.5を使用していますが、それはGentoo（Linux）のパッケージリポジトリでたまたま利用できるバージョンだからです。 GentooのメンテナーがPython 2.6＆quot; stable＆quot; * を宣言したら、それに切り替えます。もちろん、この推論は必ずしもあなたに当てはまるわけではありません。

* Python 2.6は実際には安定しています。Gentooでそのように宣言されていないのは、GentooがPythonに依存する他のプログラムに依存しているためです。繰り返しますが、この推論はおそらくあなたには当てはまりません。

Answer 2

私の会社は2.5で標準化されています。皆さんのように、100万の理由で3.0に切り替えることはできませんが、2.6に移行できることを非常に願っています。

毎日コーディングを行うと、ドキュメントを調べて、必要なモジュールまたは機能を正確に見つけることができますが、それから小さな注釈が追加されます：バージョン2.6の新機能

最新バージョンを使用すると言います。減価償却の警告が表示された場合（おそらく非常に少ないでしょう）、それを行うためのより良い方法を見つけてください。全体的に、コードは2.6で改善されます。

Answer 3

私にとってpython 2.5+に固執する最も重要なのは、多くのプラグインシステムを変更した ctypes を公式にサポートしているためです。

2.3 / 2.4で動作するctypeを見つけることはできますが、公式にはバンドルされていません。

だから私の提案は2.5です。

Answer 4

今のところ2.5.2に固執しています。私たちの技術スタックはDjangoを中心にしています（しかし、他にもたくさんのビットやボブがあります）。

epydoc 3.0.1で動作するように、docutilsを0.4に戻す必要がありました。これまでのところ、これは大きな問題ではありませんでしたが、ある時点でepydocの使用を再考する可能性があります。

2.6アップグレードは開発計画の一部です。予算はありますが、スケジュールは今のところ決まっていません。

3.0のアップグレードも同様に、人々に思い出させるものです。予算が必要です。 Djangoが3.0に跳躍しない限り、今年はそれを行いません。来年やるかもしれません。

Answer 5

最良の解決策は、全体的な均一性への希望を放棄することだと思いますが、共通の環境を持つことは努力するべきものです。次の最適なインタープリターバージョンにアップグレードするときなど、常にバージョンの問題に直面します。

したがって、問題ごとに対処する代わりに、リリース管理をよく見てこの問題を解決できます。

ソースをリリースする代わりに、プラットフォームに依存するバイナリを使用します（ソース配布に加えて）。

だからあなたがやることは、例えば、サポートされているCPUの数を定義することです： x86-32、x86-64、sparc

次に、どのオペレーティングシステム： Linux、Windows、Solaris、FreeBSD

各OSについて、多数のメジャーバージョンをサポートしています。

次のステップは、それらすべてのバイナリを提供することです。

はい、これにはかなりのインフラ投資と、リポジトリからの自動構築のセットアップが必要になります（持っていますか？）。

利点は、ユーザーがインストールするものが「1つ」だけであり、バージョンを簡単に切り替えたり、バージョンを混在させたりできることです。実際、リリース管理にあまり影響を与えずに、このアプローチでさまざまなプログラミング言語を使用することもできます。