Perpustakaan asyncio Python , yang diperkenalkan pada tahun 2012 untuk membawa pengaturcaraan asinkron kepada bahasa tersebut, sedang menghadapi kritikan yang semakin meningkat daripada pembangun yang berhujah bahawa ia mempunyai terlalu banyak kecacatan reka bentuk dan masalah kebolehgunaan. Perpustakaan ini bertujuan untuk menyediakan alternatif kepada threading tradisional untuk pengaturcaraan serentak, tetapi perbincangan komuniti mendedahkan kekecewaan yang meluas terhadap pelaksanaannya.
Mekanisme Pembatalan Yang Rosak Mencipta Masalah Kepada Pembangun
Salah satu isu yang paling ketara dengan asyncio ialah sistem pembatalannya. Tidak seperti threading tradisional di mana pembatalan sememangnya sukar, asyncio sepatutnya memudahkan perkara ini. Walau bagaimanapun, pembangun melaporkan bahawa mekanisme pembatalan tersebut rosak secara asasnya. Apabila sesuatu tugasan dibatalkan, isyarat pembatalan boleh hilang secara tidak dijangka, meninggalkan operasi berjalan selama-lamanya walaupun selepas ia sepatutnya dihentikan. Ini mewujudkan situasi di mana aplikasi tergantung atau menggunakan sumber secara tidak perlu, menjadikannya amat sukar untuk membina aplikasi yang kukuh yang boleh mengendalikan gangguan dengan baik.
Masalah Pengurusan Memori Membawa Kepada Ralat Misteri
Satu lagi titik kesakitan utama ialah mesej ralat terkenal Task was destroyed but it is pending . Ini berlaku kerana asyncio tidak menyimpan rujukan kuat kepada tugasan, yang boleh menyebabkan tugasan dikutip sampah semasa ia masih berjalan. Pembangun kerap menghadapi ralat yang mengelirukan ini tanpa panduan yang jelas tentang cara memperbaikinya. Punca utama terletak pada sistem rujukan lemah asyncio , yang direka untuk mencegah kebocoran memori tetapi sebaliknya mencipta tingkah laku yang tidak dapat diramal dan sukar untuk dinyahpepijat.
Kerumitan API Tahap Rendah Mengecewakan Pembangun
API soket dan rangkaian asas dalam asyncio dikritik kerana terlalu rumit dan penuh dengan perangkap. Operasi mudah yang sepatutnya mudah memerlukan pembangun memahami butiran rumit tentang gelung peristiwa dan deskriptor fail. Kerumitan ini menyukarkan pembangun untuk menulis kod rangkaian yang boleh dipercayai tanpa pengetahuan mendalam tentang dalaman asyncio .
Masalah Utama asyncio yang Dikenal Pasti oleh Komuniti
| Masalah | Penerangan | Kesan |
|---|---|---|
| Pembatalan Rosak | Isyarat pembatalan boleh hilang, menyebabkan tugasan berjalan tanpa had | Aplikasi tergantung atau menggunakan sumber yang tidak perlu |
| Ralat Pemusnahan Tugasan | "Task was destroyed but it is pending" disebabkan rujukan lemah | Mesej ralat yang mengelirukan dan tingkah laku yang tidak dapat diramal |
| API Tahap Rendah yang Kompleks | API soket dan rangkaian memerlukan pengetahuan mendalam tentang dalaman sistem | Sukar untuk menulis kod rangkaian yang boleh dipercayai |
| Isu Pelaksanaan Queue | Pengendalian corak pengeluar-pengguna yang lemah | Keadaan perlumbaan dan aplikasi yang tergantung |
Pelaksanaan Queue Menambah Komplikasi Yang Tidak Perlu
Malah corak asas seperti hubungan pengeluar-pengguna menggunakan Queue asyncio adalah bermasalah. Pelaksanaan baris gilir tidak mengendalikan senario biasa dengan baik, seperti memberi isyarat dengan betul apabila tiada lagi item akan dihasilkan. Ini membawa kepada keadaan perlumbaan dan aplikasi yang tergantung, memaksa pembangun melaksanakan penyelesaian yang rumit untuk apa yang sepatutnya menjadi corak komunikasi yang mudah.
Komuniti Mencari Alternatif Yang Lebih Baik
Komuniti Python sedang aktif membincangkan alternatif kepada pendekatan asyncio . Sesetengah pembangun menyokong penyelesaian monkey-patching gevent , yang membolehkan kod yang sama berfungsi dalam kedua-dua konteks sinkron dan asinkron. Yang lain menunjuk kepada bahasa seperti Go , yang mengendalikan konkurensi tanpa masalah pewarnaan fungsi yang melanda asyncio .
Saya benar-benar berharap komuniti telah bersatu di sekitar gevent - tiada async/await, sebaliknya setiap perkara yang mungkin boleh menyekat dalam perpustakaan standard dipatch-monyet untuk menghasilkan kepada gelung peristiwa.
Perbincangan juga menyentuh kebimbangan yang lebih luas tentang evolusi Python . Ramai pembangun merasakan bahawa Python telah menjadi kembung dengan ciri-ciri seperti asyncio , petunjuk jenis, dan padanan corak yang ditambah untuk bersaing dengan bahasa lain tetapi tidak berintegrasi dengan baik dengan falsafah teras Python .
Alternatif yang Dicadangkan Komuniti
- gevent: Pendekatan monkey-patching yang membenarkan kod yang sama untuk sync/async
- anyio: Lapisan antara muka di atas asyncio untuk mengatasi kekurangan
- Konkurensi gaya Go: Bahasa tanpa masalah "function coloring"
- Stackful coroutines: Serupa dengan pelaksanaan Lua berbanding stackless
Jalan Ke Hadapan Masih Tidak Jelas
Walaupun perpustakaan seperti anyio cuba menyediakan antara muka yang lebih baik di atas asyncio , isu reka bentuk asas kekal. Sesetengah ahli komuniti mencadangkan bahawa Python memerlukan peningkatan versi utama untuk menangani masalah ini dengan betul, sama seperti bagaimana peralihan Python 2 kepada 3 membenarkan perubahan yang memecahkan. Walau bagaimanapun, kerumitan usaha sedemikian dan pengajaran yang dipelajari daripada migrasi sukar itu menjadikannya tidak mungkin dalam masa terdekat.
Situasi asyncio menyerlahkan cabaran yang lebih luas dalam reka bentuk bahasa: bagaimana untuk menambah ciri moden tanpa menjejaskan kesederhanaan dan keanggunan yang menjadikan bahasa itu popular pada mulanya. Buat masa ini, pembangun Python mesti sama ada mengatasi batasan asyncio atau mempertimbangkan pendekatan alternatif untuk pengaturcaraan serentak.