Menulis kode yang masih akan berjalan bertahun-tahun dari sekarang
Bahasa pemrograman berubah. Perpustakaan berubah. Beberapa kode dari 5, 10, atau bahkan 20 tahun yang lalu mungkin masih berjalan dan menghasilkan hasil yang diharapkan, sedangkan beberapa kode dari 2 tahun mungkin gagal dengan kesalahan sintaksis. Ini sebagian tak terhindarkan, karena bahasa berkembang (paling tidak, sebagian besar memang demikian). Pengembang memiliki tanggung jawab untuk mempertahankan kode mereka. Tetapi kadang-kadang, stabilitas adalah persyaratan penting dalam kode produksi, dan kode harus berjalan selama 10 tahun tanpa perlu seseorang melalui kode setiap tahun untuk menyesuaikannya untuk perubahan bahasa. Atau saya mungkin punya skrip kecil, misalnya untuk analisis data ilmiah, yang perlu saya tinjau kembali setelah tidak menyentuhnya selama bertahun-tahun. Sebagai contoh, di kantor meteorologi ada banyak kode Fortran operasional bahkan untuk bagian-bagian yang tidak penting, dan stabilitas kode adalah salah satu alasannya. SAYA' Telah mendengar rasa takut akan ketidakstabilan adalah salah satu objek yang mereka miliki terhadap pindah ke Python (selain dari inersia bahasa tentu saja; itu hanya mungkin untuk kode baru tidak tergantung pada kode lama). Tentu saja, salah satu strategi untuk kode stabil adalah membekukan seluruh sistem operasi. Tapi itu tidak selalu layak.
Saya menggunakan Python seperti pada contoh, tetapi masalah ini tidak terbatas pada Python pada khususnya.
Dokumen tentang masalah kompatibilitas Python
Dalam kasus Python, ada beberapa dokumen yang menguraikan kebijakan untuk perubahan yang tidak kompatibel ke belakang.
PEP-5
Menurut PEP 5 :
Setidaknya harus ada periode transisi satu tahun antara rilis versi transisi Python dan rilis versi yang tidak kompatibel mundur. Pengguna akan memiliki setidaknya satu tahun untuk menguji program mereka dan memigrasikannya dari penggunaan konstruksi yang sudah usang ke yang alternatif.
Secara pribadi, saya menganggap bahwa satu tahun agak pendek. Itu berarti saya mungkin menulis beberapa kode, dan 1½ tahun dari sekarang tidak akan berjalan lagi.
PEP 291
PEP 291 berisi daftar pedoman hal-hal yang tidak lengkap yang harus dihindari untuk menjaga kompatibilitas. Namun, ini hanya berhubungan dengan Python 2.x. Karena Python 2.7 adalah rilis final dalam seri 2.x dan Python 2.7 hanya bugfix, PEP ini sekarang hanya menarik secara historis.
PEP 387
Ada juga PEP 387 tentang perubahan yang tidak kompatibel ke belakang. PEP 387 adalah konsep dan bukan kebijakan resmi. Pada Juni 2009, ini dibahas di milis Python-ideas . Bagian dari diskusi difokuskan pada bagaimana pengembang dapat menulis kode yang kuat terhadap perubahan bahasa. Satu posting mencantumkan beberapa saran tentang apa yang tidak boleh dilakukan :
Seiring dengan ini ada beberapa aturan yang dapat Anda simpulkan yang mungkin benar sebagian besar waktu: jangan panggil hal yang dimulai dengan
"_", jangan tambal sulam apa pun, jangan gunakan penggantian kelas dinamis pada objek dari kelas selain dari Anda sendiri , jangan bergantung pada kedalaman hierarki warisan (misalnya, tidak".__bases__[0].__bases__[0]"), pastikan pengujian Anda berjalan tanpa menghasilkan DeprecationWarnings, perhatikan potensi konflik namespace saat menambahkan atribut ke kelas yang diwarisi dari perpustakaan lain. Saya pikir semua hal ini tidak ditulis di satu tempat.
Selain itu, ada beberapa poin tentang "ladang ranjau" (fitur baru yang kemungkinan akan berubah) dan "area beku" (API yang dijual sangat dijamin tidak akan berubah). Mengutip Antoine Pitrou :
Saya pikir "area beku" harus didefinisikan secara positif (API publik eksplisit dan perilaku yang dijamin secara eksplisit) daripada negatif ("bidang ranjau" eksplisit). Kalau tidak, kita akan lupa untuk meletakkan beberapa hal penting di ladang ranjau dan digigit kemudian ketika kita perlu mengubah hal-hal itu dengan cara yang tidak kompatibel ke belakang.
Tampaknya tidak ada kesimpulan apa pun dari utas ini, tetapi cukup mendekati inti dari apa yang saya cari. Threadnya hampir empat tahun, jadi mungkin situasinya telah berubah atau membaik. Kode seperti apa yang mungkin bertahan, dan kode jenis apa yang lebih rapuh?
Pedoman porting
Selain dokumen yang diuraikan di atas, setiap versi Python dilengkapi dengan pedoman porting : porting ke Python 3.2 , porting ke Python 3.3 , dll.
Kompatibilitas yang berguna
PEP 3151 memperkenalkan saya pada konsep kompatibilitas yang bermanfaat . Dalam kata-kata saya sendiri, ini bermuara pada gagasan bahwa hanya jika kode ditulis dengan hati-hati pengembang bahasa perlu berhati-hati untuk menjaga kompatibilitas. Itu tidak benar-benar mendefinisikan kompatibilitas yang berguna , tetapi saya pikir itu mirip dengan ide-ide yang saya kutip dari diskusi PEP 387 di atas.
Dari sudut pandang programmer
Sebagai seorang programmer, saya tahu bahwa Python akan berubah di masa depan dan bahwa orang - terutama saya sendiri - akan mencoba menjalankan kode saya mungkin beberapa tahun dari sekarang dalam versi Python yang satu, dua, atau mungkin tiga versi minor. Tidak semuanya akan kompatibel, dan sebenarnya mudah untuk membuat kode yang akan gagal (saya pernah menemukan kode yang menyatakan if sys.version[:3] != '2.3': print 'Wrong version, exiting'). Yang saya cari adalah seperangkat pedoman tentang apa yang harus dilakukan dan apa yang tidak boleh dilakukan untuk meningkatkan peluang bahwa kode saya akan tetap berjalan tanpa diubah di masa depan.
Apakah ada pedoman seperti itu? Bagaimana cara menulis kode Python yang masih akan berjalan di masa depan?
Pertanyaan saya berhubungan baik dengan inti Python, ke perpustakaan standar, tetapi juga untuk umum digunakan add-on perpustakaan, khususnya numpy, scipy, matplotlib.
EDIT : Sejauh ini, dua jawaban berhubungan dengan python2 vs python3. Bukan itu yang saya maksud. Saya tahu tentang alat untuk bermigrasi dari Python2 ke Python3. Pertanyaan saya terkait dengan perubahan bahasa yang belum datang . Kita bisa melakukan lebih baik daripada bola kristal dalam menemukan pedoman pengkodean yang lebih stabil. Sebagai contoh:
import modulelebih tahan masa depan daripadafrom module import *, karena yang terakhir dapat memecahkan kode jikamoduletumbuh satu atau lebih fungsi / kelas baru.Menggunakan metode tidak berdokumen mungkin kurang bukti di masa depan daripada menggunakan metode yang terdokumentasi, karena sesuatu yang tidak berdokumen mungkin merupakan tanda sesuatu yang belum stabil.
Ini semacam nasihat pengkodean praktis yang saya cari. Karena ini tentang masa kini → masa depan, kita dapat membatasi diri pada Python3, karena Python2 tidak akan berubah lagi.