Saya pikir saya akan menambahkan sedikit pada strategi yang dianjurkan oleh jawaban Wim - dapatkan versi Django yang tepat bekerja pada 2.7 dan 3.x pertama - dan uraikan beberapa taktik yang bekerja untuk saya.
Python 2.7 adalah pod pelarian Anda, hingga Anda menarik pelatuk pada 3.x
- tes Anda harus dijalankan pada keduanya
- jangan gunakan fitur spesifik 3.x, seperti f-string
- pertama Python 3.x, baru kemudian Django 2.x yang tidak berjalan pada 2.7
- mulai lebih awal, jangan terlalu banyak menganalisis, tetapi hindari pendekatan big bang
- file demi file pada awalnya.
- mulai dengan kode level terendah, seperti pustaka utilitas, yang Anda miliki untuk test suites.
- jika memungkinkan, cobalah untuk secara bertahap menggabungkan perubahan Anda ke 2,7 cabang produksi dan tetap memperbarui kode port 3.x Anda dengan perubahan prod.
Django versi minor mana yang memulai?
Kriteria saya di sini adalah bahwa migrasi Django dapat dilibatkan secara adil (dan sebenarnya membutuhkan lebih banyak pemikiran daripada 2 => 3 pekerjaan). Jadi saya akan pindah ke 1,11 terbaru dan terhebat dengan cara itu Anda sudah memberikan nilai kepada pengguna 2,7 Anda. Mungkin ada sejumlah shims kompatibilitas pra-2.x yang baik pada 1.11 dan Anda akan mendapatkan peringatan penghentian 2.x.
Versi minor apa dari Python 3.x untuk memulai?
Yang terbaik untuk mempertimbangkan semua sudut, seperti ketersediaan lib pihak ke-3 Anda, dukungan dari suite CI / devops Anda dan ketersediaan pada gambar OS server yang Anda pilih. Anda selalu dapat menginstal 3.8 dan mencoba menginstal pip dari requirement.txt Anda sendiri, misalnya.
Leverage git (atau apa pun SCM yang Anda gunakan) dan virtualenv .
- pisahkan
requirement.txtfile, tetapi ...
- jika Anda memiliki git repo berbasis file, Anda dapat mengarahkan setiap venv pada codeline yang sama dengan a
pip install -e <your directory>. itu berarti bahwa, di 2 terminal yang berbeda Anda dapat menjalankan 2.7 dan 3.x terhadap unittest yang sama.
- Anda bahkan dapat menjalankan server Django 2.7 dan 3.x secara berdampingan pada port yang berbeda dan arahkan Firefox dan Chrome pada mereka.
- sering melakukan (setidaknya pada cabang porting) dan belajar tentang git bisect .
memanfaatkan 2to3
Ya, itu akan merusak 2,7 kode dan Django jika Anda membiarkannya. Begitu...
jalankan dalam mode pratinjau atau terhadap satu file. melihat apa yang rusak tetapi juga melihat apa yang dilakukannya dengan benar.
throttle ke hanya konversi tertentu yang tidak melanggar 2.7 atau Django. print x=> print (x)dan except(Exception) as e2 tidak punya otak.
Ini adalah apa yang tampak seperti perintah tercekik saya:
2to3 $tgt -w -f except -f raise -f next -f funcattrs -f print
- jalankan file-per-file sampai Anda benar-benar percaya diri.
gunakan sed atau awk daripada editor Anda untuk konversi massal.
Keuntungannya adalah, ketika Anda menjadi lebih sadar akan masalah spesifik aplikasi Anda, Anda dapat membuat serangkaian perubahan yang dapat dijalankan pada 1 file atau banyak file dan melakukan sebagian besar pekerjaan tanpa melanggar 2,7 atau Django. Terapkan ini setelah pas 2to3 Anda yang dipercantik . Itu membuat Anda dengan pembersihan sisa di editor Anda dan mendapatkan tes Anda untuk lulus.
(opsional) mulai hitam pada kode 2.7.
hitam yang merupakan pemformat kode, menggunakan Python 3 AST untuk menjalankan analisisnya. Itu tidak mencoba menjalankan kode, tetapi itu akan menandai kesalahan sintaksis yang mencegahnya mencapai tahap AST. Anda harus bekerja beberapa pip menginstal sihir global untuk sampai ke sana dan Anda harus membeli kegunaan hitam.
Orang lain telah melakukannya - belajarlah dari mereka.
Mendengarkan # 155 Langkah-langkah praktis untuk pindah ke Python 3 harus memberi Anda beberapa ide pekerjaan. Lihatlah tautan pertunjukan untuk itu. Mereka suka membicarakan langkah Instagram (?) Yang melibatkan penyesuaian bertahap menjalankan 2,7 kode ke sintaks 3.x pada basis kode umum, dan pada cabang git yang sama, sampai hari penarik-pemicu.
Lihat juga Panduan Porting Conservative Python 3
dan Instagram Melakukan Gerakan Lancar ke Python 3 - Stack Baru
Kesimpulan
Waktu Anda untuk Django 1.11 EOL (April 2020) agak singkat, jadi jika Anda memiliki 2+ sumber daya dev untuk dilemparkan padanya, saya akan mempertimbangkan melakukan hal berikut secara paralel:
DEV # 1: mulai dengan Django 1.11 bump (teorinya adalah bahwa Django 1.11 mungkin paling baik diposisikan sebagai titik tolak ke Django 2.x), menggunakan 2.7.
DEV # 2: memulai Python 3.6 / 3.7 dari kode utilitas non-Django Anda. Karena kode 2.7 kompatibel pada titik ini, gabungkan menjadi # 1 saat Anda menggunakannya.
Lihat bagaimana kedua tugas berjalan, menilai apa risiko proyek terkait Django dan seperti apa rasa sakit Python 3. Anda sudah kehilangan Python 2.7 EOL, tetapi kerangka kerja web yang usang mungkin lebih berbahaya daripada warisan Python 2.7, setidaknya selama beberapa bulan. Jadi saya tidak akan menunggu terlalu lama untuk mulai bermigrasi dari Django 1.9 dan pekerjaan Anda melakukannya tidak akan sia-sia. Ketika Anda melihat kemajuannya, Anda akan mulai melihat risiko proyek dengan lebih baik.
Kemajuan 2to3 awal Anda akan lambat, tetapi alat dan bimbingannya cukup bagus sehingga Anda akan dengan cepat menambah kecepatan jadi jangan terlalu memikirkannya sebelum mulai mengumpulkan pengalaman. Sisi Django tergantung pada paparan Anda untuk memecahkan perubahan dalam kerangka kerja itu sebabnya saya pikir yang terbaik untuk memulai lebih awal.
PS (pendapat kontroversial / pribadi) Saya tidak menggunakan enam atau banyak perpustakaan jembatan 2-ke-3 kaleng lainnya.
Itu bukan karena saya tidak percaya - itu brilian untuk lib pihak ke-3 - tetapi saya tidak ingin menambahkan ketergantungan permanen yang kompleks (dan saya terlalu malas untuk membaca dokumennya). Saya telah menulis kode 2,7 dalam sintaks yang kompatibel dengan 3.x untuk waktu yang lama jadi saya tidak benar-benar merasa perlu untuk menggunakannya. Jarak tempuh Anda mungkin bervariasi dan tidak memulai jalur ini jika sepertinya banyak pekerjaan .
Sebagai gantinya, saya membuat py223.py (57 LOC termasuk komentar) dengan jenis konten ini, yang sebagian besar berkaitan dengan solusi untuk penghentian dan perubahan nama di perpustakaan standar.
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)
Kemudian impor dari py223 itu untuk mengatasi masalah khusus tersebut. Kemudian saya hanya akan parit impor dan memindahkan aneh isinstance(x, basestr_)untuk isinstance(x, str)tapi saya tahu sebelumnya ada sedikit untuk khawatir tentang.