Perkembangan Pengembangan CPython Tanpa GIL

 (lwn.net)
1 poin oleh GN⁺ 2023-10-22 | 1 komentar | Bagikan ke WhatsApp
  • Python steering council menyatakan niat untuk menyetujui PEP 703, yang menjadikan GIL sebagai opsi selama beberapa rilis, dan syarat akhirnya masih dalam penyesuaian
  • Build --disable-gil pada CPython 3.13 disiapkan sebagai eksperimen, dan stable ABI serta kompatibilitas wheel modul ekstensi muncul sebagai isu teknis terbesar
  • Wheel abi3 yang ada mungkin tidak langsung cocok dengan CPython 3.13 tanpa GIL, sehingga adopsi abi4, perubahan limited C API, dan peralihan makro reference count menjadi pemanggilan fungsi sedang dibahas
  • Ada kekhawatiran bahwa pip bisa salah memilih wheel untuk build dengan GIL dan build tanpa GIL; instalasi keliru yang terjadi diam-diam lebih berbahaya daripada kegagalan instalasi biasa
  • Untuk nama build tanpa GIL, free-threading diusulkan alih-alih nogil, tetapi hal ini juga harus diselesaikan bersama nama executable, shebang, instalasi paralel, dan packaging distribusi

Posisi PEP 703 dan CPython tanpa GIL saat ini

  • Python steering council pada akhir Juli menyatakan niat untuk menyetujui PEP 703, dan PEP ini berisi perubahan yang menjadikan global interpreter lock (GIL) sebagai opsi di CPython
  • Syarat persetujuan rinci belum difinalkan, tetapi diskusi implementasi terkait dan persiapan ekosistem sudah berjalan
  • Dalam jangka panjang, arahnya membayangkan satu versi CPython tanpa GIL, tetapi untuk saat ini tahapnya adalah menguji perilaku tanpa GIL pada interpreter yang dibangun dengan opsi --disable-gil
  • CPython 3.13 dijadwalkan pada Oktober 2024, dan build tanpa GIL pada versi ini bersifat eksperimental

Stable ABI dan kompatibilitas modul ekstensi

  • Sam Gross membahas bagaimana PEP 703 dan stable ABI CPython saling berkaitan di Python discussion forum
  • Stable ABI digunakan agar modul ekstensi dapat berjalan sebagai wheel biner yang sama di beberapa versi CPython, sehingga tidak perlu dibangun ulang untuk setiap rilis CPython baru
  • Ekstensi yang dibangun untuk stable ABI mungkin tidak langsung berjalan pada build CPython 3.13 tanpa GIL
  • Untuk menyelesaikan hal ini, beberapa penambahan dan perubahan pada limited C API diusulkan
    • Ekstensi yang hanya menggunakan limited C API dapat membuat biner yang memakai stable ABI
    • Usulan perubahan mencakup rencana yang sudah ada untuk mengubah sebagian makro yang menaikkan dan menurunkan reference count objek menjadi pemanggilan fungsi
  • Tujuannya adalah memungkinkan biner ekstensi yang dapat berjalan baik pada build dengan GIL maupun build tanpa GIL

abi3, abi4, dan masalah pemilihan wheel

  • Victor Stinner menilai bahwa agar eksperimen tanpa GIL berhasil, diperlukan solusi sederhana untuk ekstensi yang berjalan pada kedua jenis interpreter
  • Karena ekstensi yang dibangun untuk stable ABI pada CPython 3.12 ke bawah tidak kompatibel dengan build tanpa GIL pada 3.13 dan setelahnya, muncul opsi membuat versi ABI baru, yaitu abi4
    • Stable ABI saat ini adalah abi3
    • Nomor ABI dan nomor versi mayor CPython tidak harus selalu saling terhubung
  • Gross menilai ekstensi yang ingin mendukung tanpa GIL sampai batas tertentu dapat menerima beban membuat dua wheel biner
    • Ia lebih khawatir jika proyek tanpa GIL terlalu terikat pada perbaikan C API dan stable ABI
  • Alex Gaynor juga memiliki beberapa paket wheel abi3, tetapi menilai bahwa membuat dua wheel satu kali bukan beban yang terlalu besar
    • Namun, yang penting adalah apakah pip yang ada dan yang akan datang memilih wheel yang tepat di antara keduanya
  • Brett Cannon menilai logika pip saat ini tidak dapat membedakan kedua versi, sehingga tanpa perubahan seperti abi4, pip yang ada dan versi lama tidak akan berjalan dengan benar

Kekhawatiran terhadap perilaku salah pip yang diam-diam

  • Gross menilai dukungan untuk pip lama pada build eksperimental --disable-gil di CPython 3.13 tidak perlu terlalu dikhawatirkan
    • Alasannya, pip lama cukup sering rusak pada versi Python baru
    • Sebagai contoh, ia menyebut kasus pip==23.1.1 ke bawah yang rusak di CPython 3.13 karena tidak adanya pkgutil.ImpImporter
  • Maintainer pip, Paul Moore, menilai rusak secara eksplisit dan menginstal paket yang salah secara diam-diam adalah masalah yang berbeda
    • Ada pengguna yang memakai pip lama
    • Kegagalan eksplisit dan kesalahan diam-diam memiliki dampak berbeda bagi pengguna
  • Moore khawatir pengguna yang ingin mencoba build tanpa GIL atau free-threaded akan kehilangan semangat jika harus men-debug masalah kompatibilitas ABI
  • Gaynor juga menilai jika pip berperilaku salah secara diam-diam pada paket yang terdampak, issue bisa membanjir

Instalasi paralel dan nama executable

  • Barry Warsaw bertanya apakah ada rencana untuk memasang build dengan GIL dan build tanpa GIL bersama-sama pada sistem yang sama
  • Gross menjawab bahwa situasi ini sama seperti memasang versi Python yang berbeda
  • Cannon menilai pendekatan memasukkan dua biner ke dalam satu wheel “fat” juga mungkin
    • Namun, nama biner di dalam wheel harus berbeda
  • Diskusi nama executable berlanjut ke thread terpisah
  • Paul Moore menilai pengguna harus dapat dengan mudah menguji mode tanpa GIL dan memilih salah satu dari GIL/tanpa GIL
    • Jika proses ini sulit di Windows, macOS, Linux, dan lainnya, hal itu dapat berdampak negatif pada proyek tanpa GIL
    • Pengguna harus bisa mencobanya dengan mudah agar muncul permintaan terhadap build tanpa GIL, dan agar maintainer paket juga mendapat tekanan untuk menyediakan wheel yang kompatibel dengan tanpa GIL

Perdebatan nama nogil dan free-threading

  • Barry Scott menilai nama executable penting karena baris shebang harus menunjukkan interpreter mana yang akan dipanggil
    • Ia memberi contoh nama seperti python-nogil3, python-nogil3.13
  • Gregory P. Smith menyampaikan pendapat pribadi bahwa karena build tanpa GIL pada CPython 3.13 adalah fitur eksperimental, distribusi tidak seharusnya menaruhnya di $PATH default
    • Ia juga menilai situasi ketika nama executable yang panjang tertinggal lama di shebang tidak diinginkan
    • Ia mengusulkan untuk menunda keputusan nama instalasi sampai setelah 3.14
  • Petr Viktorin, developer Fedora, menunjukkan bahwa distribusi kemungkinan besar ingin mem-package interpreter tanpa GIL untuk eksperimen pengguna
  • Moore menilai ia ingin menentukan build free-threaded dalam bentuk seperti #!/usr/bin/env python3.13-nogil
    • Ini adalah kebutuhan untuk menghindari hardcoding path yang panjang dan tidak intuitif
  • Dalam thread terkait installer Windows yang dimulai Steve Dower, Smith menyatakan steering council ingin menghindari nama nogil
    • Alasannya, nama itu tidak tersampaikan dengan baik kepada sebagian besar developer non-core, tidak ada kebutuhan untuk mengetahui apa itu GIL, dan mengandung ekspresi negatif
    • Sebagai alternatif, istilah free-threading diusulkan
  • Gross menilai free-threading juga tidak mudah dipahami orang luar dan bukan istilah yang digunakan secara luas
  • Dalam diskusi sebenarnya, preferensi terhadap nama pendek cukup kuat, dan dari sisi itu nogil adalah kandidat terkuat
  • Perubahan konkret yang tercermin adalah penggantian tag ABI build tanpa GIL dari n menjadi t
    • t berarti threading

Usulan abi4 dan pekerjaan yang tersisa

  • Gross dan Viktorin membahas titik-titik bermasalah dalam usulan perubahan API, dan umpan balik itu mengarah pada usulan ABI baru, yaitu abi4
  • Gross telah membuat prototipe untuk ABI baru tersebut
  • Viktorin secara umum setuju dengan pendekatannya, tetapi menilai detailnya masih perlu dibereskan lebih lanjut
  • Stinner menilai diperlukan PEP untuk abi4, dan Viktorin menerima ini sebagai diskusi pre-PEP
  • Ada kebingungan tentang jaminan kompatibilitas yang diberikan oleh kombinasi versi limited C API dan abi3, dan bagian ini juga memengaruhi arah abi4
  • Penyelidikan terkait masih terus berjalan, dan ada kemungkinan diskusi tatap muka dilakukan dalam core developer sprint pada pertengahan Oktober

Rumusan persetujuan final dan dampak jangka panjang

  • Pekerjaan CPython tanpa GIL atau free-threaded terus berjalan, tetapi persetujuan final PEP 703 masih menunggu
  • Keterlambatannya memang agak panjang, tetapi PEP 703 dan dampak ikutannya kemungkinan akan sangat memengaruhi pengembangan CPython dan ekosistemnya selama lebih dari 5 tahun ke depan
  • Steering council berupaya memperjelas kriteria persetujuan
  • Thomas Wouters menyatakan bahwa ia sedang memoles rumusan persetujuan yang tepat dan berupaya memperjelas beberapa keputusan
  • Sebagian pekerjaan juga dapat berlangsung dalam core developer sprint

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-22
Pendapat di Hacker News

  • Melihat komputer modern, saya jadi berpikir bahwa paralelisme eksplisit mungkin merupakan unsur ilmu komputer yang lebih fundamental daripada yang sedang populer di buku teks
    Mungkin sekarang kita sudah berada pada tahap di mana kita harus selalu menulis kode paralel secara eksplisit

    • Karena manusia lemah dalam menalar beberapa thread sekaligus, perubahan yang lebih praktis kemungkinan besar mengarah ke sintaks deklaratif yang sudah mulai terlihat
      Misalnya, loop for digantikan oleh operasi seperti foreach, map, dan filter. Ekspresi semacam ini memberi tahu compiler/interpreter bahwa kita ingin menerapkan suatu pekerjaan ke semua item dalam struktur data, lalu menyerahkan apakah dan bagaimana memparalelkannya kepada compiler/runtime
    • Paralelisme telah bercabang ke beberapa arah
      Dalam menjalankan layanan web, tiap request sudah cukup cepat, dan manfaat paralelisme yang sebenarnya ada pada pemrosesan banyak request secara berdampingan. Di sinilah No-GIL cocok
      Jika ada banyak sub-request dalam satu request, biasanya itu ditangani dengan kode asinkron, tetapi sering kali alasannya bukan karena keuntungan performa async, melainkan karena membuat thread itu mahal atau thread pool merepotkan. Async bagus untuk throughput, tetapi buruk untuk latensi, dan ketika memparalelkan request layanan, biasanya latensi lebih menjadi kekhawatiran. Async menang terutama karena kemudahan penggunaan
      Bentuk paralelisme lain terlihat pada pekerjaan offline berskala besar. Contohnya MapReduce atau Presto, dan umumnya bentuknya mirip masalah divide-and-conquer. Pelatihan model GPU juga mirip dengan ini
      Yang tidak terjadi adalah algoritma lokal yang sangat paralel. Di layanan web, ukuran datanya kecil sehingga keuntungan latensinya kecil, implementasinya kompleks, dan biaya koordinasi antar-thread menjadi besar. Pengecualian kecilnya adalah algoritma tervectorisasi, tetapi ini berjalan di satu core sehingga tidak ada overhead koordinasi, dan inferensi online juga kembali sangat kuat tervectorisasi
    • Dalam ilmu komputer, paralelisme agak mirip dengan keamanan. Kita tahu secara abstrak bahwa itu penting, tetapi untuk mempelajarinya dengan benar perlu mencari pelatihan tersendiri
      Seiring waktu, keduanya membaik. Seperti makin banyak bahasa dan library yang secara default menjadi aman, kini makin banyak hal yang secara default bersifat paralel. Masih ada jalan panjang, tetapi saya rasa untung kita tidak melakukannya terlalu dini. Sebab teknologinya jauh membaik selama 10 tahun terakhir
      Misalnya, kita bisa membandingkan apa yang dapat dilakukan secara aman dengan Rayon di Rust dengan apa yang dulu dilakukan secara tidak aman menggunakan OpenMP di C++
      Lebih jauh di luar itu ada hal-hal seperti ini yang saya kerjakan: https://legion.stanford.edu/, https://regent-lang.org/, https://github.com/nv-legate/cunumeric
    • Saya melihat paralelisme sebagai kategori yang sama dengan manajemen memori. Sebagian besar program yang kita tulis bisa, dan seharusnya, memakai suatu bentuk manajemen otomatis, sementara manajemen manual dibiarkan untuk area yang memang membutuhkannya demi performa
      Karena ini adalah detail implementasi, jika bisa diabstraksikan agar lebih mudah dimanfaatkan, maka seharusnya begitu
    • Wiki LMAX Disruptor menyebutkan bahwa latensi rata-rata untuk mengirim pesan dari satu thread ke thread lain adalah 53 nanodetik
      Sebagai perbandingan, mutex sekitar 25 nanodetik dan akan bertambah jika ada contention, tetapi mutex adalah sinkronisasi point-to-point
      Hal bagus dari Disruptor adalah beberapa thread dapat menerima pesan yang sama tanpa banyak usaha tambahan
      https://github.com/LMAX-Exchange/disruptor/wiki/Performance-...
      https://gist.github.com/rmacy/2879257
      Saya memimpikan bahasa yang mirip Smalltalk, tetapi tetap single-thread sampai paralelisasi benar-benar masuk akal
      Saya sedang mencari masalah paralelisme yang bukan big data. Paralelisme lebih mirip menambahkan lebih banyak mobil ke jalan daripada meningkatkan kecepatan mobil. Namun saya masih mencari tahu pekerjaan apa yang perlu dilakukan pengguna desktop atau mobile secara lokal dengan memanfaatkan kekuatan matematis komputer
      Sebagai ide paralelisme, saya juga memikirkan arsitektur Itanium dan VLIW

  • Pakai saja -ng. Bisa berarti no-gil atau next-generation

    • Saya teringat gelombang besar dukungan threading di Unix. Hal yang harus dilakukan developer sangat berbeda-beda di tiap platform
      Ada flag compiler baru, flag linker baru, menautkan library berbeda, bahkan sampai memakai perintah compiler yang sama sekali berbeda. AIX khususnya begitu

  • Untuk masalah shebang, sepertinya lebih baik mengandalkan konvensi Python yang sudah ada: from __future__ import nogil
    Pada titik itu, interpreter bisa di-hot-swap

    • from __future__ import bukan pernyataan runtime, melainkan pernyataan khusus yang menunjukkan flag
      https://docs.python.org/3/reference/simple_stmts.html#future...
    • “Pernyataan future adalah direktif compiler agar modul tertentu dikompilasi menggunakan sintaks atau semantik yang akan tersedia pada rilis Python mendatang ketika fitur tersebut menjadi standar”
      Pernyataan future berlaku per modul, dan GIL/no-GIL tidak mudah masuk ke model itu
    • Jika tidak dijalankan sebagai modul pertama sekaligus import pertama, implementasinya bisa menjadi mimpi buruk

  • Setiap kali melihat usulan ini, saya bertanya-tanya bagaimana menjamin program tetap berjalan dengan benar. Banyak kode Python multithread yang ada ditulis dengan cara yang tidak aman
    Masalahnya terutama adalah data race yang berulang kali saya lihat di codebase berbagai perusahaan dan proyek open source. Program-program seperti ini tidak rusak hanya karena secara implisit bergantung pada fakta bahwa GIL hanya mengizinkan satu thread berjalan pada satu waktu
    Jika GIL hilang, program-program seperti ini akan rusak. Karena Python adalah bahasa bertipe dinamis, saya sangat meragukan akan ada static analyzer yang bisa menemukan masalah seperti ini pada program Python yang sudah ada
    Yang lebih mungkin terjadi adalah bug halus yang muncul secara nondeterministik saat runtime. Akan lebih baik kalau langsung crash, tetapi bug jenis ini kemungkinan besar berujung pada perilaku yang salah
    Mungkin usulan tanpa GIL ini memang bukan untuk dipakai di sebagian besar program. Bisa jadi ini adalah alat yang sangat terspesialisasi untuk segelintir situasi ketika programmer tahu bahwa tidak ada GIL dan bisa menulis kode sesuai kondisi itu

    • Jika sebuah program multithread memiliki data race, program itu memang sudah bermasalah. GIL tidak membuat data race menjadi mustahil
      GIL hanya berarti satu thread pada satu waktu dapat mengeksekusi bytecode Python. Interpreter yang memiliki GIL pun dapat berpindah thread di antara bytecode, dan banyak operasi Python membutuhkan beberapa bytecode. Ini termasuk metode bawaan pada tipe bawaan yang banyak orang anggap “atomik”
      Karena itu Python saat ini tetap menyediakan hal seperti lock, mutex, dan semaphore meskipun ada GIL
    • Fakta kecil yang menarik: GIL sama sekali tidak mencegah semua bug race condition
      Thread yang berebut GIL sudah bisa saling merebut GIL pada waktu yang buruk dan menimbulkan kekacauan
    • Saya memahami intinya adalah membiarkan library mendeklarasikan apakah mereka mendukung mode nogil, yaitu opt-in
      Jika program hanya berjalan tanpa GIL ketika semua dependensi mengizinkannya, seharusnya ada cukup waktu untuk memperbaiki bug semacam itu
    • Sepertinya Python no-GIL baru akan hadir setidaknya setelah 3–4 siklus rilis. Sudah setahun sejak 3.11 keluar, dan saya rasa kode Python di produksi masih banyak yang sekitar 3.8
      Jadi masalah ini mungkin baru akan ditangani dalam skala besar mendekati tahun 2030. Saya juga jarang melihat produksi yang langsung menaikkan runtime yang dipakai ke rilis terbaru
      Saya tidak ingin terdengar kasar, tetapi Steering Council sudah mengatakan mereka tidak menginginkan migrasi lain seperti dari 2 ke 3, jadi orang tidak akan memperbarui dengan enteng. Sebagian besar materi yang ada online sekarang bisa berbahaya jika sekadar disalin-tempel
    • GIL hanya melindungi interpreter. Yang bisa dilakukannya hanyalah menurunkan frekuensi masalah
      Dalam kode Python nyata ada sangat banyak bug threading

  • Bukankah OCaml juga mengalami evolusi serupa? Saya penasaran apakah ada hal yang bisa dibandingkan di antara kedua proyek itu

    • Menurut saya tidak begitu. OCaml 5, alih-alih menghapus global lock dan merusak kode lama, memperkenalkan primitive baru bernama domain yang mengelola satu atau lebih thread dengan lock bersama
      Jadi API thread lama membuat thread di dalam domain saat ini dan dapat mengisolasi kode yang mengharapkan adanya lock. Kode baru bisa membuat domain baru yang dimulai dengan satu thread. Keduanya juga bisa sengaja dipakai bersama sebagai bentuk scheduling
      Python sedang mencoba membuat lock secara global menjadi sepenuhnya opsional di luar kendali penulis library. Namun lock di Python tampaknya dijamin hanya melindungi runtime itu sendiri, sehingga sebagian besar kode yang bergantung pada lock itu kemungkinan besar memang sudah memiliki bug, dan karena itu rencana Python juga terlihat bisa dijalankan
      Kalau ada kesamaan, mungkin sebatas harus menemukan dan memperbaiki shared state yang tak terduga di seluruh codebase runtime, serta merevisi C ABI

  • Sekarang Python juga punya kesempatan mengejar Tcl dalam performa multithread: https://www.hammerdb.com/blog/uncategorized/why-tcl-is-700-f...

  • Saya lebih ingin mem-porting kode Python ke Mojo untuk mendapatkan multithreading, SIMD, dan peningkatan kecepatan lain

    • Akan bagus kalau Mojo sudah menjadi dunia yang lebih matang, tetapi saat ini sama sekali belum mendekati tingkat itu
    • Setuju. Saya malah akan menulis ulang dengan Rust, Nim, atau .NET
    • Downvote sampai -3 menunjukkan dengan jelas bahwa downvote di HN bukan soal logika, melainkan perebutan wilayah dan ego
      Tidak ingin memindahkan kode Python ke Python nogil? Kalau begitu didownvote, kira-kira begitu

  • Kalau harus diberi nama, opsi seperti python4, python3-gilfoil, python3-gilfree bisa saja

  • Arus yang saat ini berfokus pada Python tanpa GIL terasa cukup aneh. Tim Faster CPython memasang target ambisius untuk meningkatkan performa CPython sebesar 50% di setiap rilis
    Di 3.11 memang ada peningkatan nyata, tetapi masih jauh dari 50%, dan dalam banyak pengujian kami, 3.12 hasilnya mirip atau malah lebih lambat. Multithreading sungguhan tentu bagus, tetapi kami jauh lebih menginginkan performa single-thread ditingkatkan terlebih dahulu
    Tentu, saya mengakui bahwa kebutuhan kami belum tentu mewakili semua orang, dan saya berterima kasih atas semua pekerjaan yang membuat Python menjadi bahasa yang hebat. Namun tetap saja saya penasaran, apa yang saya lewatkan?

    • Menurut saya Python harus punya jawaban yang mendesak untuk penggunaan banyak core. AMD baru saja merilis CPU 96-core
      Saat ini penggunaan banyak core dilakukan lewat multiprocessing, tetapi ada banyak keterbatasan. Saya paham bahwa beberapa interpreter bisa hadir bersama hal-hal seperti coroutine, tetapi tetap saja saya lebih menyukai opsi multithreading sungguhan
    • Keduanya adalah tujuan yang sepenuhnya berbeda. Secara teori, Python multithreaded dapat membuat program tertentu lebih cepat, tetapi caranya yang penting
      Di Python nogil, misalnya, beberapa thread dapat memanggil kode C dengan shared state yang dapat diakses sebagai objek Python. Ini cukup penting untuk machine learning, dan faktanya bentuk PEP saat ini berasal dari tim PyTorch
      Performa single-thread juga penting, tetapi untuk bagian yang kritis, sudah ada workaround yang cukup baik seperti numba, Cython, dan Mojo
      Urutan juga penting. Jika nogil diperkenalkan, sebagian besar pekerjaan faster CPython bisa saja sepenuhnya dibuang, jadi tim-timnya harus berkoordinasi
      Di dunia ideal, bentuknya adalah ada mode nogil sekaligus peningkatan performa single-thread. Guido juga mengisyaratkan bahwa ia sedang mempertimbangkan JIT yang canggih
    • Bagian yang mahal secara komputasi dalam “Python” ditangani oleh library seperti numpy dan tensorflow
      Python membuat abstraksi level rendah sangat nyaman ditangani dari bahasa yang levelnya lebih tinggi. Jadi sebagai pengembang Python lama, saya tidak terlalu stres soal GIL
    • Sepertinya Anda melewatkan bahwa kebutuhan orang-orang yang dikutip dalam PEP 703 berbeda dari kebutuhan Anda: <https://peps.python.org/pep-0703/#motivation>
    • Sejauh yang saya pahami, keduanya adalah proyek terpisah di dalam CPython, dan belum tentu dikerjakan oleh orang yang sama
      Jika harus memilih salah satu, saya setuju bahwa untuk sebagian besar use case, kode single-thread yang lebih cepat memang lebih cocok. Namun tidak ada alasan kita tidak bisa memiliki keduanya

  • Kalau dilihat dengan hindsight memang jelas, tetapi seandainya pihak Python tahu betapa panjang dan menyakitkannya transisi dari 2 ke 3, rasanya mereka akan merombak internal interpreter jauh lebih besar
    Setelah transisi 12 tahun, performa single-thread masih saja buruk, dan untuk mencapai multithreading sungguhan masih ada beberapa transisi menyakitkan lagi yang tersisa
    Saya tahu kita harus bersikap baik terhadap pengembangan open source, tetapi saya bertanya-tanya, mulai titik mana boleh menyebut ini bahasa yang dikelola dengan sangat buruk?

    • Bukan dikelola dengan buruk. Python punya banyak masalah, tetapi semuanya berasal dari kesuksesan Python
      Bagian terburuk Python adalah bagian-bagian yang sulit diubah karena Python terlalu populer dan ekosistemnya terlalu besar. Karena itu, segala jenis perubahan menjadi lebih sulit akibat kompatibilitas mundur
    • Benar. Setelah waktu selama ini, multiprocessing masih saja buruk
      Ada kecenderungan terlalu cepat membela Python. Penting untuk melihatnya secara objektif tanpa bias
    • Pada titik tertentu, mungkin perlu dibuat bahasa yang sintaksnya sama dengan Python, tetapi dari awal dirancang untuk performa dan dukungan threading yang lebih baik
      Proyek yang menginginkan performa dan sintaks Python bisa pindah ke sana. Python saat ini tampak seperti terseok-seok di antara banyak tujuan dan tidak benar-benar mencapai satu pun dengan baik
    • Bahwa transisi dari 2 ke 3 akan panjang dan buruk sebenarnya bisa diprediksi, dan orang-orang juga mengatakannya saat itu
      Perl 5/6 disebut sebagai contoh. Bahkan ketika sudah jelas bahwa tidak ada yang beralih, masih butuh sekitar 5 tahun lagi sampai ada upaya untuk membuatnya lebih mudah