Python2からPython3へのコード変換の場合、PythonとDjangoのどのバージョンが最適ですか？

現在私は大企業で働いており、python2の古い大きなDjangoプロジェクトをpython3バージョンに変換する必要があるため、関連する多くの調査を行いましたが、変換に最適なPythonとDjangoのバージョンに関連する完全な答えはまだ見つかりません。

現在、旧バージョンではPython：2.7.16とDjango：1.9.13を使用しています。

誰でも私の古いバージョンのpython2からpython3への変換に最適なバージョンのPythonとDjangoを私に提案できます。

Wimの答えが提唱する戦略に少し追加したいと思いました。まず、適切なバージョンのDjangoを2.7と3.xの両方で動作させてください-そして、私のために働いたいくつかの戦術を概説します。

Python 2.7は、3.xでトリガーを引くまで、エスケープポッドです。

• テストは両方で実行する必要があります
• f-stringsなどの3.x固有の機能を使用しない
• 最初にPython 3.x、次に2.7で動作しない後のDjango 2.xのみ
• 早めに始め、分析しすぎないで、ビッグバンアプローチを避けます
  • 最初はファイルごと。
  • ユーティリティスイートのように、テストスイートがある最低レベルのコードから始めます。
  • 可能であれば、2.7の本番ブランチへの変更を徐々にマージし、3.xの移植コードを製品の変更で最新の状態に保つようにしてください。

Djangoのどのマイナーバージョンから始めますか？

ここでの私の基準は、Djangoの移行がかなり関与する可能性があることです（実際には、2 => 3の作業よりも多くの思考が必要です）。ですから、2.7のユーザーに何らかの価値を既に提供している方法で、最新かつ最高の1.11に移動します。そこ1.11の前2.xの互換性シムのかなりの数は、おそらくだと、あなたはその2.xの非推奨の警告を取得することがあります。

どのマイナーバージョンのPython 3.xから始めますか？

サードパーティのライブラリの可用性、CI / devopsスイートからのサポート、選択したサーバーOSイメージでの可用性など、あらゆる角度を考慮するのが最善です。たとえば、常に3.8をインストールして、requirements.txtを単独でpipインストールすることもできます。

レバレッジgitの（またはものは何でも使うSCM）とvirtualenvの。

• 別のrequirement.txtファイルですが...
• あなたはファイルベース、gitのレポを持っている場合、あなたはで各venvを指すことができます同じコードラインを持ちますpip install -e <your directory>。つまり、2つの異なる端末で、同じユニットテストに対して2.7と3.xを実行できます。
• 異なるポートで2.7と3.xのDjangoサーバーを並べて実行し、FirefoxとChromeを指すようにすることもできます。
• 頻繁に（少なくとも移植ブランチで）コミットし、git bisectについて学びます。

2to3を利用する

はい、可能であれば2.7コードとDjangoが壊れます。そう...

• プレビューモードまたは単一のファイルに対して実行します。何が壊れているかを確認するだけでなく、何が正しく行われたかも確認してください。

• 2.7やDjangoを壊さない特定の変換のみに絞ってください。 print x=> print (x)とexcept(Exception) as e2つの簡単な方法です。

これは私のスロットルされたコマンドがどのように見えるかです：

2to3 $tgt -w -f except -f raise -f next -f funcattrs -f print

• 本当に自信があるまで、ファイルごとに実行してください。

一括変換には、エディタではなくsedまたはawkを使用してください。

利点は、アプリの特定の懸念に気づくにつれて、1つのファイルまたは多くのファイルで実行できる一連の変更を構築し、2.7またはDjangoを壊すことなくほとんどの作業を実行できることです。適度に絞った2to3パスの後でこれを適用します。これにより、エディターの残留クリーンアップが残り、テストに合格します。

（オプション）2.7コードで黒の実行を開始します。

コードフォーマッターである黒は、Python 3 ASTを使用して分析を実行します。コードを実行しようとはしませんが、ASTステージに到達できないようにする構文エラーにフラグを立てます。ただし、そこに到達するには、いくつかのPIPインストールグローバルマジックを使用する必要があり、ブラックの有用性を購入する必要があります。

他の人々はそれをやった-彼らから学ぶ。

＃155を聞くPython 3に移行するための実際的な手順を実行すると、作業のアイデアが得られます。そのためのショーのリンクを見てください。彼らは、一般的なコードベースで同じgitブランチ上で2.7コードを3.x構文に実行する段階的な調整を含むInstagram（？）の動きについて、引き金になる日まで話し合うのが大好きです。

The Conservative Python 3 Porting Guideも参照してください

とInstagramがPython 3にスムーズに移行 -新しいスタック

結論

Django 1.11 EOL（2020年4月）までの時間はかなり短いため、2つ以上の開発リソースを投入する場合は、以下を並行して行うことを検討します。

• DEV＃1：2.7を使用して、Django 1.11バンプ（Django 1.11はおそらくDjango 2.xへのジャンプオフポイントとして最適に配置されるという理論）から始めます。

• DEV＃2：非DjangoユーティリティコードのPython 3.6 / 3.7から始めましょう。この時点でコードは2.7互換であるため、必要に応じてコードを＃1にマージします。

両方のタスクの進行状況を確認し、Django関連のプロジェクトリスクと、Python 3の問題点を評価してください。すでにPython 2.7 EOLがありませんが、少なくとも数か月は、古いWebフレームワークはレガシーPython 2.7よりもおそらく危険です。ですから、Django 1.9からの移行を開始するのに時間がかかりすぎないので、そのための作業が無駄になることはありません。進行状況を見ると、プロジェクトのリスクがよりよく見えるようになります。

最初の2to3の進行は遅くなりますが、ツールとガイダンスは十分に優れているため、すぐに速度を上げることができるので、経験を積む前にそれを考えすぎないでください。Django側は、フレームワークの重大な変更への露出に依存しているため、早めに開始するのが最善だと思います。

PS（物議を醸す/個人的な意見）私は6つまたは他の缶詰の2対3ブリッジライブラリをあまり使用しませんでした。

それは私がそれを信頼していないからではなく-サードパーティのライブラリにとっては素晴らしい-むしろ、複雑な永続的な依存関係を追加したくなかったからです（そして、そのドキュメントを読むのが面倒すぎた）。3.x互換の構文で2.7コードを長い間書いていたので、それらを使用する必要性を本当に感じていませんでした。 あなたのマイレージは変化する可能性があり、多くの作業のように思われる場合は、この道に着手しないでください。

代わりに、私はこのタイプのコンテンツでpy223.py（57 LOCコメントを含む）を作成しました。そのほとんどは、標準ライブラリの非推奨と名前変更の回避策に関係しています。

try:
    basestring_ = basestring
except (NameError,) as e:
    basestring_ = str

try:
    cmp_ = cmp
except (NameError,) as e:
    # from http://portingguide.readthedocs.io/en/latest/comparisons.html
    def cmp_(x, y):
        """
        Replacement for built-in function cmp that was removed in Python 3
        """
        return (x > y) - (x < y)

次に、そのpy223からインポートして、これらの特定の問題を回避します。後でインポートを破棄isinstance(x, basestr_)してisinstance(x, str)、奇妙なものに移動しますが、事前に心配する必要はほとんどありません。

まずDjango==1.11.26、Python 2とPython 3の両方をサポートするDjangoの最新バージョンであるにアップグレードすることをお勧めします。今のところ、現在のバージョンのPython 2.7をそのまま使用します。

1.10.xと1.11.xのリリースノートをよく読み、非推奨かどうかを確認し、1.9.xコードで機能しなくなったものを修正します。物事は壊れます。Djangoは速く動きます。大規模なDjangoプロジェクトの場合、多くのコード変更が必要になる可能性があり、サードパーティのプラグインやライブラリを多数使用している場合は、それらのバージョンを調整する必要がある場合があります。サードパーティの依存関係の一部はおそらく完全に放棄されているため、代わりのものを見つけるか、機能を削除する必要があります。

各バージョンのアップグレードのリリースノートを見つけるには、「Djangoの新機能」をググってください。ヒットは、すべての非推奨と変更を綿密に文書化します。

• https://docs.djangoproject.com/en/2.2/releases/1.10/
• https://docs.djangoproject.com/en/2.2/releases/1.11/

Webアプリケーションは、すべてのテストが合格で、Djangoの1.11上で正常に動作することが表示されたら（あなたが行う権利、テストスイートを持っている？）、あなたは同じDjangoのバージョンを維持しながら、Pythonの3の変換を行うことができます。Django 1.11は最大でPython 3.7をサポートしているので、これはターゲットとして適切なバージョンです。バイトとテキストの間の暗黙的な変換がなくなり、多くのPython 2 Webアプリケーションがそれに依存しているため、あらゆる場所でUnicodeが期待されます。

プロジェクトがDjango 1.11とPython 3.7で正常に動作しているように見えたら、以前と同じプロセスに従って、Django 3.0へのアップグレードを検討できます。リリースノートを読み、必要な変更を加え、テストスイートを実行し、チェックアウトします。開発サーバーのwebappを手動で。

最初にpy3にアップグレードします。あなたは見てする必要がありますsetup.py安定/ 1.9.xブランチ（上Djangoのレポでhttps://github.com/django/django/blob/stable/1.9.x/setup.py PY3ことを把握するために）サポートされているバージョンは3.4（デッド）および3.5です。

py3.5とDjango 1.9を使用している場合は、目的のバージョンになるまで一度に1つずつアップグレードできます。たとえば、Django 1.11はpy3.5とpy3.7をサポートしているため、

py27/dj19 -> py35/dj19 -> py35/dj1.11 -> py37/dj1.11 ... -> py37/dj2.2

dj2.2はpy3.8をサポートする最初のバージョンですが、通常保守的な環境で作業している場合は、おそらくpy37 / dj2.2で停止します。

他のパッケージがある場合は、各ステップで連携するバージョンの組み合わせを見つける必要があります。計画を立てることが重要であり、一度に1つのコンポーネントのみをアップグレードすると、通常は時間を節約できます。

将来のライブラリ（https://python-future.org/）は、py27と3.xの両方で実行するコードが必要である一方で、多くの厄介な状況で役立ちます。6も素晴らしいです。私はあなた自身の互換性レイヤーを転がすことを避けます（なぜ車輪を再発明するのですか？）

可能な場合は、開始する前にユニットテストのカバレッジを最大75〜85％にして、各アップグレードステップの「開始」バージョンと「終了」バージョンの両方で自動テストを確実に設定してください。次のバージョンにアップグレードする前に、Djangoからのすべての警告を読んで修正してください。Djangoは下位互換性をほとんど考慮しないため、通常、アップグレードパスのすべてのマイナーバージョンにアクセスすることをお勧めします（または、少なくとも非互換性」および各マイナーバージョンの非推奨リスト）。

幸運（300 + Klocコードベースをpy27 / dj1.7からアップグレードしているので、私はあなたの痛みを感じます;-)

私のプロジェクトにも同じ種類の問題があり、Djangoバージョン2.2.7でpython 3.7.5を試しました。

pythonの最新バージョン3.8またはDjango最新バージョン3.0を使用しないでください。あらゆる種類のバグが原因で、最新バージョンの適切な解決策が得られない可能性があるためです。

現在のバージョンで撮影してみてください。Python 3.8およびDjango3.0。Sixライブラリは、いくつかの規則の変更に役立ちます。どちらの方法でも、リファクタリングを行う必要があるので、それを最新のものにすることもできます。