Halo, Habr! Saya mempersembahkan untuk Anda terjemahan artikel
Menuju "Kernel Python" oleh Glyph Lefkowitz (pembuat kerangka Twisted).
Lebih detail - di bawah potongan.
Keajaiban meminimalkan perpustakaan standar
Di bawah pengaruh
pidato Amber Brown bulan lalu di Pertemuan Tingkat Tinggi Python (merujuk pada laporannya di bulan Mei “Baterai menyala, tetapi baterai bocor” - komentar penerjemah), Christian Hymes melanjutkan
pekerjaannya untuk mengurangi perpustakaan Python standar dan membuat proposal
PEP 594 untuk penghapusan eksplisit. fragmen usang dan tidak didukung itu.
Munculnya PEP 594 ("Menghapus Baterai Mati dari Perpustakaan Standar") adalah berita bagus bagi para pythonis, terutama mereka yang mendukung perpustakaan standar dan sekarang akan memiliki front pekerjaan yang lebih kecil. Tur singkat galeri PEP tentang modul-modul usang atau berbasis-penghapusan berbicara untuk dirinya sendiri (modul sunau, xdrlib, dan chunk adalah favorit pribadi saya). Pustaka Python standar berisi banyak modul yang berguna, namun, itu juga termasuk kode necropolis nyata, sebuah monumen yang menjulang dari fragmen usang yang mengancam untuk mengubur pengembang mereka setiap saat.
Namun, saya percaya bahwa pendekatan yang salah dapat diterapkan dalam kalimat PEP ini. Pustaka standar saat ini didukung bersama dengan pengembang CPython. Potongan-potongan besar itu ditinggalkan dengan harapan samar bahwa suatu hari nanti akan menguntungkan seseorang. Dalam PEP tersebut di atas, prinsip ini dapat diamati ketika melindungi modul colorsys. Mengapa tidak menghapusnya? Jawab: “Modul ini diperlukan untuk mengubah warna CSS antara sistem koordinat (RGB, YIQ, HSL dan HSV). [Dia] tidak mengenakan biaya tambahan pada pengembangan inti. "
Ada saat-saat ketika akses Internet terbatas, dan mungkin merupakan ide yang bagus untuk memuatkan Python dengan satu ton material, tetapi saat ini modul yang diperlukan untuk mengubah warna antara sistem koordinat yang berbeda berjarak satu langkah dari perintah instalasi pip.
Mengapa Anda tidak mempertimbangkan permintaan kolam renang saya?
Jadi, mari kita lihat pernyataan ini: apakah modul kecil seperti colorsys memaksakan "biaya tambahan pada pengembangan inti"?
Cukup bagi pengembang utama bahwa mereka berusaha mempertahankan basis kode C yang besar dan kuno, yaitu CPython sendiri. Seperti yang dikatakan Marietta Viggia dalam
pidatonya di North Bay Python, pertanyaan paling umum yang diajukan oleh pengembang kernel adalah: "Mengapa Anda belum melihat permintaan kumpulan saya?" Dan apa jawabannya?
Lebih mudah untuk mengabaikan permintaan kumpulan ini. Itulah artinya menjadi pengembang kernel!
Orang mungkin bertanya, apakah Twisted memiliki masalah yang sama? Twisted juga merupakan koleksi besar modul yang digabungkan secara longgar; semacam perpustakaan standar untuk jaringan. Apakah semua klien dan server ini untuk SSH, IMAP, HTTP, TLS, dll. dll. mencoba memeras semuanya menjadi satu paket?
Terpaksa menjawab:
ya . Twisted bersifat monolitik karena berasal dari periode historis yang sama dengan CPython, ketika instalasi komponen sangat rumit. Karena itu, saya bersimpati dengan posisi CPython.
Idealnya, pada titik tertentu, setiap sub-proyek di Twisted harus menjadi proyek terpisah dengan repositori sendiri, integrasi berkelanjutan (CI), situs web dan, tentu saja, dengan pengembangnya sendiri yang lebih fokus. Kami sudah perlahan tapi pasti berbagi proyek di mana batas alami dapat dibuat. Beberapa poin yang dimulai dalam Twisted sebagai konstan dan inkremental dipisahkan, ditangguhkan dan filepath sedang dalam proses pemisahan. Proyek lain, seperti klein dan treq, terus hidup secara terpisah. Kami akan melakukan lebih banyak ketika kami menemukan cara mengurangi biaya pengaturan dan mendukung integrasi berkelanjutan dan bagaimana melepaskan infrastruktur untuk masing-masing infrastruktur.
Tetapi apakah sifat monolitik Twisted merupakan masalah yang paling mendesak atau bahkan serius untuk proyek ini? Mari kita menghargainya.
Pada saat penulisan ini, Twisted memiliki 5 permintaan pool tertunda yang belum terselesaikan sejalan. Waktu rata-rata yang dihabiskan untuk mempertimbangkan tiket adalah, secara kasar, empat setengah hari. Tiket tertua dalam antrian bertanggal 22 April, yang berarti bahwa kurang dari 2 bulan telah berlalu sejak permintaan kolam yang belum ditinjau yang tertua dikirim.
Selalu sulit untuk menemukan cukup pengembang dan waktu untuk menanggapi permintaan kumpulan. Kadang-kadang tampaknya kita masih sering mendapatkan pertanyaan, "Mengapa Anda tidak mempertimbangkan permintaan kolam renang saya?" Kami tidak selalu melakukannya dengan sempurna, tetapi secara umum kami mengelola; antrian berfluktuasi antara 0 dan 25 atau lebih di bulan yang paling sial.
Bagaimana dengan inti CPython dibandingkan dengan angka-angka ini?
Setelah
mengunjungi github , Anda dapat melihat bahwa 429 tiket sedang menunggu untuk dipertimbangkan saat ini. Yang tertua di antara mereka diharapkan mulai 2 Februari 2018, yakni hampir 500 hari.
Berapa banyak masalah dengan interpreter dan berapa banyak masalah dengan perpustakaan stdlib? Tentunya review yang tertunda adalah masalah, tetapi apakah penghapusan stdlib dapat membantu?
Untuk penilaian cepat dan tidak ilmiah, saya melihat halaman pertama (tertua) dari permintaan kumpulan. Dalam penilaian subjektif saya, dari 25 permintaan kumpulan, 14 dikaitkan dengan perpustakaan standar, 10 dengan inti bahasa atau kode penerjemah, dan satu dikaitkan dengan masalah dokumentasi kecil. Atas dasar proporsi ini, saya berani menyarankan bahwa sekitar setengah dari permintaan kumpulan yang tidak ditinjau terkait dengan kode perpustakaan standar.
Jadi, alasan pertama mengapa tim CPython utama perlu berhenti mendukung perpustakaan standar adalah karena mereka
benar-benar tidak memiliki kemampuan fisik untuk mendukung perpustakaan standar. Atau, dengan kata lain, mereka
tidak mendukungnya , dan itu tetap hanya untuk mengakuinya dan mulai berbagi pekerjaan.
Itu adalah fakta bahwa tidak ada permintaan kolam renang CPython yang terkait dengan modul colorsys. Memang, itu tidak membebankan biaya pada pengembangan kernel.
Pengembangan kernel itu sendiri membebankan biaya ini. Jika saya ingin memperbarui modul colorsys untuk mengikuti perkembangan zaman (mungkin untuk memiliki objek Warna, mungkin untuk mendukung model warna integer), kemungkinan besar saya harus menunggu 500 hari atau lebih.
Sebagai akibat dari semua ini, lebih sulit untuk mengubah kode di pustaka standar, yang menyebabkan minat pengguna yang lebih rendah dalam berkontribusi. Rilis yang jarang dari CPython juga memperlambat pengembangan perpustakaan dan mengurangi manfaat dari umpan balik pengguna. Bukan kebetulan bahwa hampir semua modul perpustakaan standar telah secara aktif mendukung alternatif pihak ketiga, dan ini bukan kesalahan pengembang stdlib. Seluruh proses dipertajam untuk menghentikan semua kecuali modul stdlib yang paling umum digunakan.
Lingkungan baru, persyaratan baru
Mungkin yang lebih penting adalah bahwa menghubungkan CPython ke perpustakaan standar menempatkan CPython sendiri dalam posisi istimewa dibandingkan dengan implementasi bahasa lainnya.
Podcast setelah
podcast ,
podcast setelah
laporan, memberi tahu kami bahwa untuk melanjutkan kesuksesan dan pengembangan Python, Anda harus tumbuh di area baru: terutama di front-end, serta klien seluler, sistem tertanam dan game konsol.
Lingkungan ini membutuhkan satu atau dua kondisi:
- runtime yang sama sekali berbeda (lihat Brython atau MicroPython )
- dimodifikasi versi dipreteli standar perpustakaan.
Dalam semua kasus ini, batu sandungan adalah definisi modul yang harus dihapus dari perpustakaan standar. Mereka harus ditemukan dengan coba-coba; Pertama-tama, proses ini benar-benar
berbeda dari proses penentuan ketergantungan standar dalam aplikasi Python. Tidak ada deklarasi install_requires di setup.py melaporkan bahwa perpustakaan menggunakan modul dari stdlib bahwa target Python runtime mungkin melompati karena keterbatasan ruang.
Masalah dapat terjadi bahkan jika semua yang kita gunakan adalah standar Python pada instalasi Linux. Bahkan distribusi Linux untuk server dan komputer desktop memiliki kebutuhan yang sama untuk paket kernel Python yang lebih kecil, sehingga pustaka standar sudah cukup terpotong di dalamnya. Ini mungkin tidak memenuhi persyaratan kode Python dan akibatnya menyebabkan kesalahan ketika bahkan
instalasi pip tidak akan berfungsi .
Singkirkan semuanya
“Bagaimana dengan anggapan bahwa kamu perlu membersihkan sedikit setiap hari? Meski kedengarannya meyakinkan, jangan biarkan diri Anda tertipu. Alasan mengapa bagi Anda pembersihan tidak pernah berakhir justru karena Anda sedikit membersihkan. [...] Rahasia utama kesuksesan adalah ini: jika Anda menghapusnya dalam satu gerakan, dan tidak secara bertahap, maka Anda dapat secara permanen mengubah pemikiran dan kebiasaan hidup Anda ”
Marie Kondo, Pembersih Ajaib. Seni Jepang Memulihkan Ordo di Rumah dan dalam Kehidupan "(hlm. 15-16)
Sementara pengurangan bertahap dari perpustakaan standar adalah langkah ke arah yang benar, perubahan bertahap saja tidak cukup. Seperti yang dikatakan Marie Kondo, jika Anda benar-benar ingin menertibkan, langkah pertama adalah
membuat semuanya tidak terlihat agar benar-benar melihat semuanya, dan hanya mengembalikan apa yang dibutuhkan saja.
Waktunya telah tiba untuk membayar upeti kepada modul-modul yang tidak lagi membesarkan hati, dan mengirimkannya jauh.
Kami membutuhkan versi Python yang hanya berisi minimum yang paling diperlukan sehingga semua implementasi bisa konsisten, dan agar aplikasi (bahkan yang bekerja di browser web atau mikrokontroler) dapat dengan mudah menyatakan persyaratannya dalam requirement.txt.
Di beberapa lingkungan bisnis, gagasan perpustakaan standar yang besar nampak menarik karena penambahan dependensi dalam persyaratan.txt bersifat birokratis, namun, "perpustakaan standar" di lingkungan seperti itu memiliki batas-batas yang murni sewenang-wenang.
Mungkin masih merupakan ide yang baik untuk memasok beberapa distribusi biner dari CPython (bahkan mungkin yang resmi) dengan berbagai pilihan modul dari PyPI. Memang, bahkan untuk tugas-tugas biasa, sejumlah perpustakaan stdlib diperlukan, yang mana pip perlu menginstal modul lain yang diperlukan.
Sekarang ada situasi di mana pip didistribusikan bersama dengan Python, tetapi
tidak dikembangkan dalam repositori CPython. Bagian dari apa yang disertakan dengan penginstal Python standar dikembangkan dalam repositori CPython, bagian datang dalam tarball terpisah untuk penerjemah.
Untuk menggunakan Linux, kita membutuhkan media yang dapat di-boot dengan sejumlah besar program tambahan. Tetapi ini tidak berarti bahwa kernel Linux itu sendiri terletak di satu repositori raksasa, di mana ratusan aplikasi yang diperlukan untuk server Linux yang berfungsi dikembangkan oleh satu tim. Kernel Linux sangat berharga, tetapi sistem operasi yang menggunakannya dibuat dari
kombinasi kernel Linux dan berbagai perpustakaan dan program yang dikembangkan secara terpisah.
Kesimpulan
Filosofi "Termasuk Baterai" idealnya cocok untuk penciptaannya; seperti roket pendorong, dikirimkan Python ke publik pemrograman. Namun, ketika ekosistem open source dan paket Python matang, strategi ini menjadi usang, dan, seperti akselerator apa pun, kita harus membiarkannya kembali ke tanah sehingga tidak menyeret kita kembali.
Runtime Python baru, tugas penerapan baru, dan pemirsa pengembang baru semua memberi komunitas Python peluang luar biasa untuk mencapai ketinggian baru.
Tetapi untuk mencapai hal ini, kita membutuhkan inti Python yang baru, lebih ringkas, dan tidak kelebihan beban. Kita perlu mengguncang seluruh perpustakaan standar ke lantai, hanya menyisakan bagian terkecil yang kita butuhkan sehingga kita dapat mengatakan: ini benar-benar perlu, tetapi itu hanya baik untuk dimiliki.
Saya berharap bahwa saya telah meyakinkan setidaknya beberapa dari Anda inti Python yang kami butuhkan.
Dan sekarang: siapa yang mau menulis
PEP ?