なぜ人々はPython 3の使用をためらうのですか？

Python 3は2008年12月にリリースされました。それから多くの時間が経過しましたが、今日でも多くの開発者はPython 3の使用をためらっています。

もちろん、Python 3にはPython 2との非互換性があり、一部の人々は後方互換性に依存する必要があります。しかし、Python 3は、ほとんどのプロジェクトがPython 3に切り替えたり開始したりするのに十分な長さではありませんか？

競合する2つのバージョンがあると、多くの欠点があります。学習者の混乱など、2つのブランチを維持する必要があります。では、なぜPython 3に切り替えることについてPythonコミュニティ全体でそんなにためらいがありますか？

この回答は更新されていないことに注意してください。http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.htmlの個人サイトでPython 3のQ＆Aがはるかに長くなっています

前の答え：

（2012年9月の状況更新）

私たち（Pythonコア開発者）は、Python 3.0がリリースされたとき、3.xが2.xシリーズの新しいプロジェクトの「デフォルト」の選択肢になるまでに約5年かかると予測していました。この予測が、2.7リリースの予定されているメンテナンス期間が非常に長い理由です。

また、元のPython 3.0リリースにはIOパフォーマンスが低いという重大な問題があり、ほとんどの実用的な目的には効果的に使用できなかったため、2009年6月下旬のPython 3.1のリリースからタイムラインを開始する方が理にかなっています。 IOパフォーマンスの問題は、3.0.zメンテナンスリリースがない理由でもあります。3.1へのアップグレードよりも3.0に固執したい理由はありません）。

執筆時点（2012年9月）で、これは現在移行プロセスに3年以上かかっていることを意味し、その予測はまだ順調に進んでいるようです。

Python 3コードを入力する人はprint、関数になるなどの構文の変更に最も頻繁に噛まれますが、自動2to3変換ツールがそれを非常に喜んで処理するため、実際にはライブラリの移植の面倒ではありません。

実際の最大の問題は、実際にはセマンティックの問題です。Python3では、Python 2のようにテキストエンコーディングを高速かつゆるく遊ばせません。これは、Python 2に対する最大の利点であると同時に、移植に対する最大の障壁でもあります。Unicode処理の問題を修正して、ポートを正しく動作させる必要があります（一方、2.xでは、そのコードの多くは、非ASCII入力。特に非ASCIIデータが一般的でない環境で動作する印象を与えます。

Python 3.0および3.1の標準ライブラリでさえ、Unicodeの処理に問題があり、多くのライブラリ（特にWebサービスに関連するライブラリ）を移植することは困難です。

3.2は、これらの問題の多くに対処し、Djangoのようなライブラリとフレームワークのはるかに優れたターゲットを提供しました。3.2 wsgirefは、3.x の最初の作業バージョン（Pythonで記述されたWebサーバーとWebアプリケーション間の通信に使用される主な標準）ももたらしました。これはWebスペースでの採用に必要な前提条件でした。

numpyのとscipyのダウンロードなどの主要な依存関係は、今のように、インストールや依存関係の管理ツールを移植されているzc.buildout、pipとvirtualenv3.xのために利用できる、ピラミッド1.3のリリースは、Python 3.2をサポートし、今後のDjangoの1.5リリースでは、実験的なPythonの3のサポートを含み、そして12.0リリースTwistedネットワーキングフレームワークは、Python 3互換バージョンを作成するための道を開くために、Python 2.5のサポートを廃止しました。

Python 3互換性ライブラリとフレームワークの進歩に加えて、人気のあるJITコンパイルされたPyPyインタープリター実装は、Python 3サポートに積極的に取り組んでいます。

移行プロセスを管理するツールも大幅に改善されました。加えて、2to3（今2.xシリーズのサポートを維持する必要がないアプリケーションのワンタイム変換に最適と考えられている）はCPythonの一部として提供されるツールもありますpython-modernize使用する、2to3ターゲットとするインフラストラクチャをPython 2およびPython 3の（大）共通サブセット。このツールは、six互換性ライブラリを使用して、Python 2.6+とPython 3.2+の両方で実行される単一のコードベースを作成します。Python 3.3リリースは、既存のUnicode対応アプリケーションを移行する際の「ノイズ」の1つの主な原因も排除します。Python3.3は、文字列リテラルの「u」プレフィックスを再度サポートします（実際にはそうしません）Python 3のすべて-Python 2でテキストとバイナリリテラルを既に正しく区別していたユーザーがPython 3への移行をうっかり難しくするのを避けるために復元されただけです。

したがって、私たちは実際に物事がどのように進行しているかにかなり満足しています-元の時間枠に進むにはまだ2年近くあり、変更はPythonエコシステム全体にうまく波及しています。

多くのプロジェクトがPython Package Indexメタデータを適切にキュレートしておらず、あまりアクティブでないメンテナーを持つプロジェクトがPython 3サポートを追加するために分岐されているため、純粋に自動化されたPyPIスキャナーは依然としてPython 3ライブラリの状態を過度に否定的に表示しますサポート。

PyPIでのPython 3サポートのレベルに関する情報を取得するための推奨される代替手段は、http： //py3ksupport.appspot.com/です。

このリストは、不正確なプロジェクトメタデータ、ソース管理ツールにあるが公式リリースにはないPython 3サポート、および最新のフォークを持つプロジェクトを考慮して、Brett Cannon（長年のPythonコア開発者）によって個人的にキュレーションされていますまたはPython 3をサポートする代替物。多くの場合、Python 3でまだ利用できないライブラリに重要な依存関係が欠けているか、他のプロジェクトでPython 3がサポートされていないためユーザーの需要が少なくなります（たとえば、コアDjangoフレームワークがPython 3、Southやdjango-celeryなどの関連ツールは、Python 3サポートを追加する可能性が高く、Pyramid と Djangoの両方でPython 3サポートが利用可能になると、Python 3サポートがgeventなどの他のツールに実装される可能性が高くなります）。

http://getpython3.com/のサイトには、Python 3の書籍やその他のリソースへの優れたリンクが含まれており、既にPython 3をサポートしている主要なライブラリとフレームワークを特定し、開発者が資金援助を求める方法に関する情報も提供しています主要プロジェクトのPython 3への移植におけるPSF。

別の優れたリソースは、新しいプロジェクトにPythonバージョンを選択する際に考慮すべき要因に関するコミュニティwikiページです：http : //wiki.python.org/moin/Python2orPython3

私は多くのためらいが2つのことから来ると信じています：

• 壊れていない場合は、修正しないでください
• [XYZライブラリ]必要な3.0ポートはありません

このドキュメントで概説されているコア言語の動作には、かなりの違いがあります。たとえば、「印刷」をステートメントから関数に変更するだけの簡単なことで、多くのPython 2.xコードが破損します。これは最も簡単なことです。3.0では、古いスタイルのクラスは完全に削除されました。実際、これらはまったく異なる言語です。したがって、古いコードの移植は、一部の人が想定しているほど単純ではありません。

既存のビジネスが、既存の機能セットに変更を加えずに、時間、お金、および労力を費やして何かに移行することを強制する理由はありません。Python 2シリーズのコードベースは長い間ビジネスで稼働しており、安定しており、テスト済みであり、現在のすべての製品機能セットを備えています。Python 3に移行するためだけにPython 3を動かすために、なぜ誰もが時間、お金、努力を費やすのでしょうか。

移行後、回帰エラーが発生しないようにし、頭痛の種はすべて避けられません。

新規プロジェクトの場合、ポリシーは単純明快で、すべて次の点から始まります。

1. Ubuntuのようなディストリビューションには、デフォルトのインストールでPython 3が含まれていますか？
2. Python 3のライブラリエコシステムとは何ですか。
3. すべてのフレームワークなどは、Python 3などと互換性があります。

その通常の「新しい言語の選択」プロセス。これが鶏卵問題の出番です。多くの人が使っていないので、多くの人はそれを使っていません。最終的には、誰もそれに移動する気にならない。

後方互換性を破ることは決して良いことではありません。最後には、常にかなりの割合のユーザーを終了させます。

Python 2.0がリリースされた頃、Pythonの人気は急速に高まっていました。古いバージョンに依存していなかったため、自然に最新バージョンを使用する新しいユーザーがたくさんいました。多くの人がデフォルトで2.0を採用しているため、ライブラリ開発者などに大きなプレッシャーがありました。

Python 3.0がリリースされた頃には、すでにPython 2.0に依存する膨大な数のユーザーがいましたが、指数関数的な成長（既存のユーザーに対して一定の係数を維持）を無期限に維持することはできません。

個人的には、Python 2の時代の新機能は、Python 3が提供する機能よりもはるかに魅力的でした。

とにかくPython 3が最終的に引き継ぐと思っていましたが、今はよくわかりません。しかし、この問題を抱えているのはPythonだけではありません。結局のところ、Perl 6を正直に使用している人は何人ですか？これは、Python 3、IIRCよりもかなり長い時間でした。

私にとって大きなショーストッパーは、自動翻訳では対処できないと思いますが、整数除算です。xを切り捨てたx / 2に依存する科学コードがあります（xが整数の場合）。

Python 3はそれをしませんが、0.5の答えを返します（奇数x）。
コード内のすべての/を//で置き換えることはできません。なぜなら、ときどきフロート除算を行い、フロートの動作が必要になるからです。

そのため、Python 3に移植するには、何万行ものコードをトロールして、すべての/をチェックし、/または//であるかどうかを判断できるかどうかを確認する必要があります。

必要なすべてのライブラリが既にPy3kに移植されている場合、Python 3は新しいプロジェクトを開始できます。

これができない場合は、Pythonの2.7を使用すると、両方の長所です：あなたは、ほとんどのPython 2.xのために作成されたすべてのライブラリを持っているとあなたが決めるとき移行が簡単になるように、あなたは徐々に、Py3k-互換性があるようにあなたのコードを変更することができますそれ。2.7で既に持っているPy3kの構文の良い点のリストはかなり長いので、からインポートすることを忘れないでください__future__。私のお気に入りはデフォルトでユニコードであり、除算は常にフロートを生成します。

Webサービスの観点から：主要なサーバーフレームワークもWebフレームワークもPython3をサポートしていません。

更新：明らかに2011年の初めにそうでしたが、現在（2013年後半）には、ほとんどの主要なフレームワークがPython3で動作しています。ただし、一部はまだ互換性がありません。重要な例はTwistedで、まだ進行中です。

あなたが重いi18nの仕事をしていない限り、私がP3Kを使用するのを見てきた説得力のある理由はありません。私の進路では、広大なユニコードが私の（ASCII）作業の障壁であり、コードを詰まらせる強制ジェネレーターであることがわかりました。

数年のうちに、3はより魅力的な環境を提供しますが、今日はそうではありません。

ディストリビューションはPython3を利用可能にしません。既にPython2から移行しているフリンジディストリビューションがいくつかあります。しかし、Debian、Ubuntuなどの主流のLinuxバリアントはサポートしていません。それがアプリケーション作成者として私がどちらもしない主な理由です。

トランジションを準備しましたが、非互換化された構文コンストラクトを避けようとしても、適切にテストすることはできません。それは本当に鶏と卵の問題に帰着します。