Requests: Pertimbangkan Penyertaan Permintaan dalam Pustaka Standar Python 3.5

Ya, karena menyederhanakan seluruh proses dan tidak mengorbankan kinerja. Jadi iya.

• Dampak seperti apa yang akan terjadi pada kemampuan Permintaan untuk berkembang dan tumbuh?
• Apakah frekuensi rilis Permintaan sesuai dengan frekuensi rilis Python? Perbedaan besar di sini mungkin merupakan indikasi yang baik bahwa stdlib bukan tempat yang tepat untuk Permintaan.

Mari kita CC beberapa orang yang pendapatnya sangat kami pedulikan:

@shazow @kevinburke @dstufft @ Alex @ sigmavirus24

Apa yang terjadi dengan "lib standar adalah tempat mati"?

Pertanyaan irama rilis bagus; Saya khawatir kehilangan kemampuan permintaan untuk berevolusi secara bebas. Yang mengatakan, mungkin perpustakaan inti permintaan akan cocok.

Nilai 2 $CURRENCY saya:

Saya akan segan melakukannya. Saya pikir berada di luar perpustakaan standar telah memberi kami kebebasan untuk membuat pilihan yang menguntungkan pengguna kami tanpa terjebak di belakang kebijakan pengembang inti untuk dukungan dan rilis versi. Ini memungkinkan kami untuk dengan hormat tidak setuju dengan prioritas pengembang inti. Dan itu memungkinkan kita untuk membuat keputusan yang bersifat ideologis, yang telah menjadi urat nadi proyek ini selama lebih dari tiga tahun.

Saya pikir kenyataannya adalah jika modul ini memasuki perpustakaan standar, tim inti saat ini akan pindah darinya. Saya tentu memiliki sedikit minat untuk mengikutinya ke dalam rawa yang merupakan pengembangan inti. Yang paling mungkin untuk menangani permintaan di stdlib adalah @sigmavirus24 , dan dia hanya satu orang. Kehilangan arah itu pasti akan menyebabkan erosi antarmuka perpustakaan dari waktu ke waktu, dan saya pikir itu akan menjadi hal yang tragis.

Satu-satunya hal yang diberikan perpustakaan standar kepada kita adalah waktu kita kembali. Itu alasan yang bagus untuk meletakkannya di sana, jika itu yang menurut Anda perlu, tetapi saya tidak berpikir kita harus berpura-pura bahwa itu akan membuat perpustakaan atau ekosistem Python menjadi lebih baik.

Saya tidak berpikir Anda benar-benar _can_ menambahkan permintaan ke stdlib tanpa terlebih dahulu menambahkan chardet dan urllib3 atau menghapus ketergantungan Anda pada mereka. Ada juga hal di mana Python tidak ingin mengirimkan CA Bundle sehingga Anda perlu memodifikasinya sehingga menggunakan bundel platform sistem seperti yang dilakukan Python secara alami sekarang.

Selain itu, saya tidak yakin. Itu pasti akan mempermudah untuk mendapatkan permintaan, namun bagian dari pekerjaan saya di pip pada dasarnya adalah membuatnya sehingga mudah untuk mendapatkan hal-hal seperti permintaan tanpa perlu menambahkannya ke stdlib. Selain itu juga agak membingungkan untuk memiliki banyak cara untuk membuat permintaan HTTP di Python stdlib. Penyatuan urllib dan urllib2 adalah hal yang baik di Python stdlib dan saya tidak berpikir bahwa menambahkannya kembali dengan urllib.request dan "requests" juga merupakan ide yang bagus. Akhirnya saya tidak berpikir itu benar-benar akan membantu banyak orang, ini hanya akan masuk ke 3.5+ sehingga siapa pun yang ingin menggunakan permintaan harus menggunakan versi yang ada di PyPI atau membuat 3.5 versi Python minimum yang didukung yang saya tidak' t berpikir adalah hal yang realistis terjadi dalam waktu dekat.

Sementara saya pikir memiliki Permintaan di perpustakaan standar akan membantu pengguna baru, saya tidak tahu bahwa itu akan membantu komunitas Python secara keseluruhan. Pengguna berpengalaman tahu cara menggunakan Permintaan dan tahu cara menginstalnya.

Saya akan sangat prihatin dengan efek mengerikan yang akan terjadi pada pengembangan baru karena orang lain akan segan untuk berkontribusi, mengetahui bahwa mereka tidak akan melihat perubahan kontribusi mereka dalam rilis yang mudah digunakan untuk waktu yang lama.

Bagaimana dengan jalan tengah untuk membuat distribusi Python dikirimkan dengan itu diinstal secara default?

Tidak.

permintaan sama sekali tidak cocok untuk penyertaan stdlib karena banyak alasan yang disebutkan di depan saya. Ketergantungan urllib3 sendiri adalah showstopper yang lengkap; kami tidak ingin itu mati di stdlib.

Apa yang _akan_ berguna adalah menambahkan sesuatu _basic_ dan serupa dengan permintaan yang dibangun di atas sumber daya http stdlib saat ini yang memungkinkan pengguna melakukan permintaan get/post sederhana ke https tanpa mempraktikkan sihir darah.

Juga pengingat yang baik bahwa itu akan ditambahkan ke Python 3 saja. :) (dan tidak lebih awal dari Python 3.6).

Apakah Anda mulai lelah mempertahankannya Kenneth? ;)

Saya tidak berpikir kita bahkan dapat mulai membahas pertanyaan ini tanpa seseorang mengatakan apa yang menjadi httplib, urllib, dan teman-teman. Menambahkan permintaan tanpa mengatasi kompleksitas pilihan, menurut saya, lebih buruk daripada jawaban "abaikan stdlib, gunakan saja permintaan". Ini adalah regresi ke hari-hari urllib, urllib2.

Saya pikir kenyataannya adalah jika modul ini memasuki perpustakaan standar, tim inti saat ini akan pindah darinya. Saya tentu memiliki sedikit minat untuk mengikutinya ke dalam rawa yang merupakan pengembangan inti. Yang paling mungkin untuk menangani permintaan di stdlib adalah @sigmavirus24 , dan dia hanya satu orang. Kehilangan arah itu pasti akan menyebabkan erosi antarmuka perpustakaan dari waktu ke waktu, dan saya pikir itu akan menjadi hal yang tragis.

Saya akan mengembara ke stdlib untuk mencoba membantu, tetapi mengingat fakta bahwa salah satu dari saya tidak tahu berapa banyak patchset sebelumnya yang saya kirimkan telah diterima dan satu _reviewed_ lainnya membuat saya khawatir ingin repot dengan proses itu. Saya tahu para pengembang inti sepenuhnya dibanjiri oleh hal-hal yang lebih penting. Saya juga tahu orang lain telah memutuskan secara acak bahwa mereka ingin mempertahankan httplib/http tetapi mereka jelas tidak cocok untuk pekerjaan itu (belum) dan saya tidak memiliki kesabaran untuk mengerjakan httplib ketika menambal yang saya dan @Lukasa duduk sekitar, tidak ditinjau, dan tidak dipedulikan (ketika mereka memperbaiki masalah mendesak dengan perpustakaan).

Saya mungkin akan berakhir hanya meminta permintaan untuk terus menggunakannya.

permintaan sama sekali tidak cocok untuk penyertaan stdlib karena banyak alasan yang disebutkan di depan saya. Ketergantungan urllib3 sendiri adalah showstopper yang lengkap; kami tidak ingin itu mati di stdlib.

Itu selalu menjadi perdebatan @kennethreitz (dan oleh karena itu, proyek secara keseluruhan) bahwa urllib3 adalah detail implementasi. Banyak fitur terbesar permintaan ditangani sepenuhnya oleh urllib3, tetapi itu tidak berarti mereka tidak dapat diimplementasikan kembali dengan hati-hati ke perpustakaan yang benar-benar tanpa ketergantungan.

Mengenai ketergantungan chardet: itu tidak lain adalah sakit kepala bagi kami (dan bagi saya secara khusus). Dulu memiliki basis kode terpisah untuk py2 dan py3 sampai saya memasukkannya ke dalam perpustakaan basis kode tunggal (yang hanya dalam beberapa bulan terakhir telah digabungkan kembali ke chardet yang tepat). Perpustakaannya lambat dan memiliki memori besar (yang membuat marah banyak orang sampai-sampai meneriaki kami di sini tentang pelacak masalah). Ini tidak sepenuhnya akurat dan universalchardet Mozilla yang dimodelkan telah ditinggalkan oleh Mozilla. Jadi menghapus chardet mungkin akan menjadi hal yang positif.

Mengenai apakah kita harus melakukan ini atau tidak, sejujurnya saya tidak peduli. Apa pun yang ada di stdlib akan berakhir menjadi permintaan di API saja. Tingkat adopsi Python 3 cukup lambat sehingga saya tidak berpikir orang akan terpengaruh secara signifikan oleh ini selama N tahun ke depan (di mana N adalah jumlah tahun yang tidak diketahui secara global selama 3,5 untuk digunakan dalam produksi oleh perusahaan).

Dan seperti yang saya katakan, saya mungkin hanya akan meminta permintaan atau menggunakan urllib3 secara langsung pada saat itu.

Saya membahas ini panjang lebar dengan Guido tempo hari — chardet harus dimasukkan terlebih dahulu. Saya pikir urllib3 dan permintaan dapat dimasukkan ke dalam paket http bersama.

Namun, saya sangat cenderung setuju dengan @hynek dan @dstufft. Mungkin permintaan baik-baik saja apa adanya :)

Either way, jika Anda memiliki pendapat yang ingin Anda bagikan, Anda dipersilakan untuk membagikannya di sini (atau kapan saja sebenarnya).

:berkilau: :kue: :berkilau:

Juga, menambahkan modul http baru ke stdlib tanpa asyncio-story sepertinya
gila bagi saya.

Pada Sun 25 2015 Jan di 1:15:51 Kenneth Reitz [email protected]
menulis:

Either way, jika Anda memiliki pendapat yang ingin Anda bagikan, Anda
selamat datang untuk berbagi di sini (atau kapan saja benar-benar).

[gambar: :kilau:] [gambar: :kue:] [gambar: :kilau:]

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71384152
.

Saya tidak berpikir kita bahkan dapat mulai membahas pertanyaan ini tanpa seseorang mengatakan apa jadinya httplib, urllib, dan teman-teman

Ini adalah masalah saya. Saya pikir keadaan membingungkan saat ini harus diselesaikan terlebih dahulu.

:+1: :logam:

Untuk memperjelas, komentar saya di atas tentang menerapkan kembali urllib3 untuk dimasukkan dalam stdlib tidak boleh dianggap enteng. Jumlah pekerjaan yang diperlukan untuk melakukan itu akan sangat besar karena urllib3 adalah produk dari (kemungkinan 10 atau lebih) tahun pekerjaan pengembang.

Saya juga telah berbicara dengan Guido tentang melemparkan urllib3 ke stdlib beberapa tahun yang lalu dengan kesimpulan bahwa itu bukan ide yang bagus, tapi saya cukup netral tentang hal itu pada saat ini.

API urllib3 sebagian besar telah stabil dan hampir sepenuhnya kompatibel ke belakang selama beberapa tahun sekarang. Kecepatannya mungkin bahkan lebih lambat daripada stdlib hari ini, dengan sebagian besar perubahan berupa perbaikan kecil atau peningkatan keamanan (dengan penambahan fitur yang kompatibel ke belakang sesekali seperti batas waktu/pencobaan ulang granular). Jika seseorang benar-benar ingin mencoba dan memasukkan urllib3 ke perpustakaan standar, menurut saya itu bukan ide yang buruk—ini bukan ide _best_.

(Saya tidak berbicara untuk permintaan, karena bergerak dengan kecepatan yang sangat berbeda dengan tujuan yang berbeda dari urllib3.)

Ide terbaik, menurut saya, adalah untuk PSF untuk menyewa (atau mungkin Kickstart atau sesuatu) 1-3 pengembang untuk membangun perpustakaan http baru di atas asyncio dengan dukungan HTTP/2 dengan inspirasi besar dari urllib3, permintaan , dan hiper. Saya akan senang melihat sebanyak mungkin kode diambil kata demi kata tetapi ditata dengan cara yang konsisten, modular, dan dapat digunakan kembali. Idealnya targetkan Python 4 atau sesuatu, dan singkirkan semua urllibs dan httplibs. Saya berharap ini akan menjadi kerja keras 6-9 bulan, tetapi mungkin lebih.

Bagian terburuk tentang urllib3, yang ingin saya lihat diganti jika seseorang mencoba menulis ulang sesuai saran @ sigmavirus24 , adalah bahwa itu tergantung pada httplib. fungsionalitas urllib3 secara substansial terbatas dengan banyak kode yang dihabiskan untuk mengatasi kekurangan httplib. Meskipun jika dukungan HTTP/2 akan dianggap serius dalam tujuan ini, maka cakupan implementasi ulang HTTP/1.1 akan menjadi bagian yang sangat menghibur dari pekerjaan yang diperlukan.

Banyak PyCons yang lalu, sekelompok dari kami bertemu dan membuat papan tulis tata letak perpustakaan http baru yang mengubah semua bagian menjadi pengaturan ideal yang dapat kami bayangkan pada saat itu. Saya akan dengan senang hati menggali catatan ini jika ada yang akan mencoba ini.

+1 @shazow

Sekali lagi, jika ada yang menemukan diri mereka dengan waktu dan kecenderungan untuk mengambil proyek yang cukup besar itu, saya telah membuat sketsa desain API diduga yang mungkin menjadi titik awal yang baik.

Ya karena satu-satunya cara saya akan mengizinkan permintaan sebagai ketergantungan adalah jika itu di stdlib.

Yang mengatakan, urllib3 berisi fitur yang sangat diinginkan orang, jadi memilikinya di stdlib sudah cukup bagi saya

Apakah Anda tidak menggunakan dependensi apa pun?

@dstufft ini ada dalam proyek yang umumnya tidak, di mana semua orang tidak dapat diganggu untuk mencari cara menggunakan urllib. (orang tidak menambahkannya sebagai dep karena ssl/etc secara umum, tetapi karena kemalasan)

@dstufft juga

Sementara saya menghargai beberapa orang yang ingin mengembangkan dependensi tanpa ketergantungan pada perangkat lunak lain yang tidak mengubah API-nya selama bertahun-tahun, ini bukan tempat untuk diskusi.

@ sigmavirus24 saya tidak setuju. permintaan telah mengalami perubahan API di masa lalu. API berubah, itu sebabnya kami memiliki versi, itu sebabnya dependensinya kompleks. Ini adalah kasus yang sempurna untuk diskusi itu karena permintaan adalah ketergantungan dalam banyak proyek.

Jika Anda pindah ke stdlib, API harus stabil.

@dcramer API rusak tepat sekali, di 1.0. API memang berubah, tetapi API permintaan juga tidak merencanakan perubahan apa pun. Satu-satunya perubahan yang kami miliki adalah menambahkan parameter json yang tidak merusak apa pun. Anda dapat terus menuduh kami melanggar API terlalu banyak, tetapi ketika proyek seperti OpenStack memiliki persyaratan yang ditetapkan sebagai >=1.2.3 untuk waktu yang lama, saya pikir itu mengatakan banyak tentang stabilitas permintaan. API telah stabil, tepatnya karena setelah kami memotong 1.0, kami menolak semua tambahan baru ke API (dengan pengecualian yang jelas baru-baru ini menambahkan param json ) dan kami sangat ketat untuk tidak melanggar API. Jika Anda bukan konsumen permintaan, Anda tidak akan tahu ini. Jadi saya tidak menganggap ketidaktahuan Anda secara pribadi.

Lebih lanjut jika stdlib API seharusnya sangat stabil, jelaskan mengapa argparse merusak API publiknya antara Python 3.3 dan 3.4?

@ sigmavirus24 Anda sekarang murni mengubah ini menjadi debat API. Saya hanya menunjukkan alasan saya tidak memasukkannya karena itu dapat berubah, dan semua orang menggunakannya, dan setiap orang menggunakan versi yang berbeda. Sangat bagus bahwa kalian tidak pernah mengubah API Anda, tetapi saya tidak punya keinginan atau waktu untuk mengikutinya atau menganggap itu benar.

Anda tahu Python juga mengubah API-nya, sebenarnya cukup sering, terkadang dengan cara yang sangat besar, mungkin Anda pernah mendengar tentang Python 3?

Yah aku meninggalkan perdebatan ini. Saya membuat pendapat saya jelas. Tidak yakin apa yang Anda semua mengomel tentang.

Saya pikir beberapa pertanyaan kunci untuk dijawab adalah:

1. Bagaimana Anda ingin dokumentasi standar (termasuk tutorial) berubah? Pustaka standar HTTP API saat ini berasal dari era di mana menghilangkan detail protokol yang bersaing (misalnya FTP vs HTTP) dianggap sebagai pendekatan yang diinginkan. Dalam satu setengah dekade berikutnya, komunitas pengembangan web telah berkumpul di HTTPS+JSON sebagai pendekatan yang lebih disukai untuk interaksi klien/server gaya permintaan/respons untuk sebagian besar kasus penggunaan selain eksekusi perintah jarak jauh (yang menggunakan SSH atau Windows RCP), dan API permintaan adalah implementasi klien standar de facto dari model itu untuk aplikasi Python modern.
2. Apakah Anda ingin API permintaan ditingkatkan dari standar de facto ke standar de jure, sehingga secara otomatis disertakan dalam semua saluran redistribusi CPython, didukung oleh jaminan dukungan jangka panjang CPython (dan redistributor komersial kami), serta semua kegiatan pendidikan "perpustakaan standar saja"? (Yang terakhir ini masih sangat umum, karena kriteria untuk digunakan di lingkungan perusahaan sering kali menyertakan dukungan dan jaminan IP, yang dimiliki CPython, tetapi permintaan tidak. Dalam situasi saat ini, banyak pengguna tidak akan mempertimbangkan permintaan sebagai opsi karena terlalu banyak pekerjaan bagi mereka untuk membuatnya terakreditasi untuk digunakan)
3. Modul lain apa di pustaka standar yang dapat ditingkatkan dengan memiliki permintaan seperti API untuk dibangun?
4. Apakah akan lebih baik untuk menjaga permintaan itu sendiri tidak berubah sebagai implementasi versi independen dari API, dan sebagai gantinya menambahkan permintaan baru yang terinspirasi API ke perpustakaan standar, mirip dengan cara Guido mendekati pekerjaan standardisasi ayncio?

Sejauh gagasan pekerjaan pengembangan terkelola PSF berjalan, saya akan sangat menentangnya, karena kami tidak memiliki infrastruktur manajemen untuk menangani hal semacam itu. Proposal hibah yang menyarankan PSF berkontribusi pada upaya crowdfunded di bidang ini akan menjadi cerita yang berbeda (tidak ada jaminan tanpa proposal khusus untuk ditinjau, tetapi itu tentu saja merupakan ide yang dapat kami diskusikan).

Perhatikan bahwa beberapa vendor mungkin sudah mendistribusikan ulang permintaan, tetapi "apakah mereka juga menyediakan dukungan untuk permintaan?" menjadi pertanyaan terpisah yang harus kami tanyakan kepada vendor atau penyedia platform. Jadi dalam konteks manajemen risiko jangka panjang (pikirkan tahun dan dekade, bukan minggu atau bulan) tergantung pada itu berarti kita harus menanggung risiko dan tanggung jawab swadaya jika hulu bosan dan beralih ke sesuatu yang lain, atau yang lain menerima potensi pengurangan tingkat pilihan yang kami miliki di penyedia platform.

Dengan perpustakaan standar, kami umumnya tidak memiliki masalah itu - sementara redistributor terkadang merusak sesuatu, dalam konteks komersial, vendor yang memecahkan barang yang berfungsi di hulu memberi Anda cukup banyak pengaruh untuk membuat vendor yang melanggar memperbaikinya.

Oh, satu pertanyaan kunci lain yang harus dijawab sebelum menjadi sukarelawan untuk benar-benar memelihara barang-barang di perpustakaan standar: apakah Anda siap menerima tanggung jawab perangkat lunak pengiriman yang membantu menggerakkan separuh bursa saham dunia, adalah salah satu bahasa paling populer untuk infrastruktur perusahaan, satu dari bahasa paling populer untuk pemrograman ilmiah (termasuk digunakan untuk perencanaan lintasan pada misi luar angkasa antarplanet), salah satu bahasa paling populer untuk pengembangan web, dan salah satu bahasa utama yang digunakan dalam inisiatif literasi komputer baru di lembaga pendidikan?

Apakah Anda juga siap untuk melakukan itu sementara memiliki orang-orang yang bekerja pada layanan non-kritis di mana tingkat keandalan yang sangat rendah (seringkali kurang dari 99% uptime) dapat diterima dengan baik mengeluh bahwa masalah kepercayaan Anda yang mendalam tidak beralasan, dan hanya masalah politik tersembunyi yang bodoh yang mereka tidak dapat diganggu tentang diri mereka sendiri dengan?

Juga, asumsi keliru yang ingin saya perbaiki: sebagian besar programmer Python kemungkinan besar bahkan tidak akan pernah mendengar tentang pip, apalagi permintaan. Ini adalah orang-orang yang menjalankan skrip dalam sistem Python pada rilis Linux dukungan jangka panjang, orang-orang yang sebagian besar pengembang open source dengan cepat mengekspresikan penghinaan yang tak terucapkan, tanpa berhenti untuk mempertimbangkan keadaan apa yang mungkin terjadi untuk membuat pendekatan mereka menjadi ide yang baik.

Waktu siklus adopsi dalam komunitas ini secara inheren diukur dalam tahun. Hanya sebagian kecil dari industri yang saat ini menjalankan CI yang cukup ketat untuk dapat melaju lebih cepat, dan kebanyakan orang di fraksi itu tidak tertarik untuk melambat cukup lama untuk mendengarkan kekhawatiran mereka yang memiliki banyak masalah. infrastruktur yang perlu kita kelola dan modernisasikan.

Bagian pasca jurang dari kurva adopsi teknologi adalah yang kami capai ketika kami mengatakan "ya, pendekatan ini sekarang cukup matang sehingga kami dapat mendorongnya, atau sesuatu berdasarkan itu, ke dalam perpustakaan standar untuk membantu menjadikannya benar-benar universal. anggapan".

Sebagai contoh yang lebih konkret tentang bagaimana gelembung filter "komunitas sumber terbuka" dapat mengubah perspektif kami: Jenkins memegang lebih dari 70% pangsa pasar dalam penerapan CI perusahaan.

Berhati-hatilah dalam mengandalkan intuisi tentang apa yang "semua orang tahu", ketika Anda mendasarkan perspektif itu pada individu dan organisasi yang sangat terlibat dalam open source. Sebagian besar pengembangan perangkat lunak masih merupakan pekerjaan khusus untuk memenuhi kebutuhan organisasi tertentu, dan sebagian besar orang yang melakukannya masih mendapatkan alat dan informasi mereka dari vendor komersial daripada komunitas open source.

@dcramer
Tidak yakin apa yang Anda semua mengomel tentang.

Bahasa yang sangat tepat untuk debat ini. Ketika counter yang sah dibuat untuk posisi Anda, Anda menggunakan cercaan yang dimaksudkan untuk merendahkan wanita. Par untuk kursus sekalipun. Bergerak,

@ncoghlan

Poin 1: Saya pikir dokumentasi akan disederhanakan secara drastis dengan permintaan (permintaan-sama) di stdlib. Salah satu hal pertama yang saya lakukan ketika belajar bahasa baru adalah mencari tahu bagaimana melakukan HTTP. Memiliki fitur itu adalah sesuatu yang bermanfaat bagi panduan ini.

Poin 2: Ada perbedaan antara API dan perpustakaan secara de facto vs. de jure. API dapat dengan mudah disediakan oleh perpustakaan standar. Saya pikir kekhawatiran Anda tentang dukungan akan lebih ditujukan pada permintaan (kode) yang disertakan.

Re poin 3 & 4: Saya tidak yakin itu sesuatu yang akan dibahas di sini. Mungkin ide python akan lebih baik.

Sejauh gagasan pekerjaan pengembangan terkelola PSF berjalan, saya akan sangat menentangnya, karena kami tidak memiliki infrastruktur manajemen untuk menangani hal semacam itu.

Itu menarik. Saya tidak berpikir itu kemungkinan tetapi akan lebih bagus untuk memiliki sesuatu yang lebih baik daripada http (lib).

Dengan perpustakaan standar, kami umumnya tidak memiliki masalah itu - sementara redistributor terkadang merusak sesuatu, dalam konteks komersial, vendor yang memecahkan barang yang berfungsi di hulu memberi Anda cukup banyak pengaruh untuk membuat vendor yang melanggar memperbaikinya.

Saya tidak yakin leverage apa yang Anda bicarakan. Saya telah melihat surepip, venv, dan hal-hal lain yang rusak oleh Debian dan redistributor lainnya di CPython. Itu tangensial untuk diskusi ini sekalipun.

Oh, satu pertanyaan kunci lain yang harus dijawab sebelum menjadi sukarelawan untuk benar-benar memelihara barang-barang di perpustakaan standar: apakah Anda siap menerima tanggung jawab perangkat lunak pengiriman yang membantu menggerakkan separuh bursa saham dunia, adalah salah satu bahasa paling populer untuk infrastruktur perusahaan, satu dari bahasa paling populer untuk pemrograman ilmiah (termasuk digunakan untuk perencanaan lintasan pada misi luar angkasa antarplanet), salah satu bahasa paling populer untuk pengembangan web, dan salah satu bahasa utama yang digunakan dalam inisiatif literasi komputer baru di lembaga pendidikan?

Seperti yang telah disebutkan, sebagian besar orang yang saat ini terlibat tidak akan melanjutkan proyek. Saya mungkin akan menjadi satu-satunya orang tetapi mengingat rekam jejak saya dengan pengembangan CPython hulu, itu tidak akan produktif meninggalkan beban itu kepada pengembang inti yang ada (dan masa depan lainnya).

Bagian pasca jurang dari kurva adopsi teknologi adalah yang kami capai ketika kami mengatakan "ya, pendekatan ini sekarang cukup matang sehingga kami dapat mendorongnya, atau sesuatu berdasarkan itu, ke dalam perpustakaan standar untuk membantu menjadikannya benar-benar universal. anggapan".

Kenyataannya adalah bahwa orang-orang itu tidak akan pernah mengejar, bukan? Orang-orang masih menjalankan perangkat lunak pada Python 2.4 dan 2.5. Load balancer F5 masih hanya mendukung Python 2.5. 2.7 akan digunakan mungkin sampai akhir kehidupan alami saya (yang saya harap akan cukup lama). Apakah ini benar-benar orang-orang yang paling terpengaruh oleh keputusan ini? Orang-orang yang sama yang Anda gambarkan mungkin tidak pernah membuat lompatan ke Python 3. Dan saat ini, masih _leap_. Mungkin pada saat mereka memutuskan untuk mempertimbangkannya, Python 3.8 atau 3.9 atau 4.2 akan keluar dan tidak akan merepotkan mereka.

Benar, poin utama saya adalah bahwa tujuan penyertaan pustaka standar _sangat_ berbeda dari tugas yang lebih umum untuk menyediakan pustaka sumber terbuka untuk digunakan oleh pengembang sumber terbuka lainnya. Jika tim permintaan memilih untuk terus menyediakan hanya perpustakaan yang dikelola secara independen (layanan komunitas yang sangat saya syukuri, kalian melakukan pekerjaan yang hebat!), dan tidak mendukung dorongan untuk standarisasi API, maka kami akan mengandalkan pada redistributor seperti RHEL/Fedora/CentOS, Debian/Ubuntu, ActiveState, Enthought, dan Continuum Analytics untuk mengambil modul dan menstandarkannya _anyway_, sehingga orang dapat menganggapnya akan selalu tersedia (atau setidaknya cukup sering bagi mereka untuk menjadi senang mengandalkan API dalam skrip file tunggal yang tidak sepenuhnya dikemas dengan deklarasi ketergantungan yang sesuai). Namun, sebagian besar dokumentasi pengantar kemungkinan masih akan mengarahkan orang untuk melakukan HTTP dengan cara perpustakaan standar, jadi apakah orang diajari "HTTP untuk Python, edisi 2001" atau "HTTP untuk Python, edisi 2015" akan bergantung pada apakah mereka mengambilnya dari sumber "hanya perpustakaan standar", atau yang mencakup modul pihak ketiga yang direkomendasikan.

Seperti halnya virtualenv dan PEP 405, atau Twisted+Tornado vs asyncio, atau ipaddr vs ipaddress, saya tidak percaya masuk akal untuk memasukkan _requests sendiri_ di perpustakaan standar. Sebaliknya, saya pikir lebih masuk akal untuk mendukung penyertaan _inspired_ API permintaan yang meninggalkan semua kode kompatibilitas lintas versi, bundling sertifikat, dll, dll, dan hanya membawa API dan dokumentasi default untuk menangani permintaan HTTP yang diautentikasi hingga 2015 standar. Kemudian pada tahun 2030, kami akan mengeluh tentang betapa kunonya desain _requests_ API pada standar 2030 ("HTTP? Siapa yang menggunakannya lagi?!?!"), tapi tidak apa-apa, hanya saja bagaimana siklus ini bekerja (sampai AJAX pertama dan kemudian JSON datang, XML-RPC adalah raja bukit). Jika Anda mendapatkan 5 tahun dari desain API sebelum orang mulai mengeluh tentang tanggal, Anda melakukannya dengan cukup baik, 10 mengesankan, dan 15 benar-benar spektakuler.

Hal utama yang diperlukan untuk memulai proses itu adalah seseorang yang cukup termotivasi oleh gagasan agar API permintaan tersedia di mana-mana untuk memperjuangkan upaya standardisasi, melakukan pekerjaan implementasi, dan bertujuan untuk berkomitmen pada setidaknya beberapa tahun pertama pemeliharaan stdlib. Alternatifnya adalah terus sangat bergantung pada redistributor untuk menjangkau pengembang yang tidak mau dan/atau tidak dapat mengunduh dan menjalankan kode arbitrer dari internet (kategori yang mencakup semua orang di industri apa pun dengan persyaratan uji tuntas peraturan yang ketat, serta siapa pun bekerja untuk organisasi lain dengan selera risiko yang sama rendahnya).

Mengenai beberapa poin lain, leverage saat ini dengan Debian relatif lemah, sedangkan leverage lebih baik dengan redistribusi yang didukung secara komersial di mana pelanggan yang membayar dapat mengeluh secara langsung tentang hal-hal yang rusak relatif terhadap harapan yang ditetapkan oleh kami sebagai komunitas pengembangan hulu.

Dalam hal siklus pembaruan, salah satu hal utama yang disampaikan standardisasi hulu (bahkan dalam Python 3) adalah konsensus komunitas. Pada saat itu, perpustakaan yang merupakan "backport" dari fitur Python 3 menjadi lebih mudah untuk membenarkan bundling dengan Python 2. Saya pribadi masih ingin melihat rilis sumo dari Python 2 yang melakukan bundling itu (unittest2, subprocess32, enum34, contexlib2 , trollius, dll), tetapi itu adalah pertempuran politik yang terpisah dalam dirinya sendiri, terutama dalam hal meyakinkan orang-orang bahwa minat dan sumber daya untuk mempertahankan distribusi sumo independen redistributor semacam itu hingga 2020 benar-benar tersedia.

@dcramer terima kasih telah memberi kami waktu Anda — ini sangat dihargai :heart:

@sigmavirus24 semuanya baik-baik saja :)

Saya tidak punya banyak untuk ditambahkan di bagian depan inklusi stdlib, selain, itu
akan rapi untuk melihat beberapa PEP atau utas atau berbicara tentang apa yang harus dilakukan
di Python stdlib, dan mungkin untuk melihat kembali tahun lalu atau lebih
pengembangan dari perspektif, "bagaimana menangani masalah ini"
berbeda jika ini adalah modul di perpustakaan standar".

Karena ini mungkin menjadi utas de facto yang dilihat orang ketika mereka mengatakan
"apa yang harus kita tambahkan/ubah ketika mempertimbangkan untuk menambahkan Permintaan ke stdlib",
Saya ingin memberikan teriakan lain untuk memperbarui hierarki pengecualian. Saya
biasanya memiliki dua pertanyaan ketika permintaan gagal - a) Apa saja?
implikasi? dan b) Dapatkah saya mencoba kembali permintaan dengan aman?
Kegagalan pencarian DNS dan pipa yang rusak memiliki implikasi yang sangat berbeda,
tetapi permintaan saat ini mengelompokkan keduanya sebagai ConnectionError. Saya telah merinci beberapa
dari pekerjaan yang terlibat di sini:
https://Gist.github.com/kevinburke/b98e053a4bf9835c67bb

Senang berdiskusi lebih banyak dengan orang-orang yang tertarik.

Kevin Burke
telepon: 925.271.7005 | dua puluhmilidetik.com

Pada Sun, Jan 25, 2015 at 08:15, ncoghlan [email protected] menulis:

Sebagai contoh yang lebih konkret tentang bagaimana filter "komunitas open source"
gelembung dapat mengubah perspektif kita: Jenkins memegang lebih dari 70% pangsa pasar
dalam penerapan CI perusahaan.

Berhati-hatilah dalam mengandalkan intuisi tentang apa yang "semua orang"
tahu", ketika Anda mendasarkan perspektif itu pada individu dan
organisasi yang sangat terlibat dalam open source. Sebagian besar
pengembangan perangkat lunak masih pekerjaan kustom untuk memenuhi kebutuhan a
organisasi tertentu, dan sebagian besar orang yang melakukannya adalah
masih mendapatkan alat dan informasi mereka dari vendor komersial bukan
daripada komunitas open source.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/kennethreitz/requests/issues/2424#issuecomment -71413074
.

FWIW, saya pikir kata-katanya di http://docs.python-requests.org/en/latest/dev/philosophy/ ,

Essentially, the standard library is where a library goes to die.
It is appropriate for a module to be included when active 
development is no longer necessary.

mungkin salah tafsir. Bagi saya, kedengarannya seperti sikap merendahkan terhadap Perpustakaan Standar, yang tentu saja tidak terdiri dari perpustakaan mati. Saya kesal dan menahan diri untuk tidak menggunakan permintaan, sampai saya menemukan halaman ini, yang merupakan diskusi yang menarik dan jauh lebih baik daripada kata-kata di atas.