Numpy: Permintaan: gunakan pembuatan versi semantik

Bisakah numpy dianggap menggunakan versi semantik, tetapi dengan 1 ?

Perhatikan bahwa hampir setiap proyek Python ilmiah inti melakukan apa yang dilakukan NumPy: menghapus kode yang tidak digunakan lagi setelah beberapa rilis kecuali itu sangat mengganggu, dan hanya menabrak nomor versi utama untuk, yah, hal-hal utama.

Tidak yakin apakah Anda mengusulkan perubahan pada kebijakan penghentian, atau jika menurut Anda kami seharusnya menggunakan versi 14.0.0 dan bukan 1.14.09 sekarang.

Yang terakhir: NumPy kira-kira pada versi 14 sekarang. Tapi saya mengusulkan untuk mengadopsi konvensi ini hanya untuk rilis mendatang.

BTW: Pendahulu NumPy, Numeric, memang menggunakan versi semantik dan sampai ke versi 24 selama kurang lebih satu dekade. Saya tidak tahu mengapa ini diubah dalam transisi ke NumPy.

Kesan saya adalah bahwa sebagian besar proyek Python tidak menggunakan versi semantik. Misalnya, Python sendiri tidak menggunakan pembuatan versi semantik. (Saya juga tidak mengetahui adanya sistem operasi atau kompiler utama yang menggunakan semver - apakah Anda punya beberapa dalam pikiran?) Saya setuju bahwa pendukung semver telah melakukan pekerjaan yang bagus dalam memasarkannya, membuat banyak pengembang berpikir bahwa itu bagus ide, tapi AFAICT itu pada dasarnya tidak bisa dijalankan di dunia nyata untuk proyek apa pun yang lebih besar dari kiri-pad, dan saya sangat membantah gagasan bahwa orang-orang setengah sekarang "memiliki" format MAJOR.MINOR.MICRO tradisional dan semua orang harus beralih ke sesuatu lain.

Dapatkah Anda memberikan contoh yang Anda maksud dengan "skema pelabelan rilis yang tidak dapat disalahartikan sebagai pembuatan versi semantik"? Menggunakan nama, bukan angka? Anda mengutip versi berbasis tanggal, tetapi skema yang paling umum untuk ini yang pernah saya lihat adalah yang digunakan oleh misalnya Twisted dan PyOpenSSL, yang saat ini masing-masing di 17.9.0 dan 17.5.0. Itu tampak seperti versi semver yang sangat masuk akal bagi saya ...

Dan dapatkah Anda menjelaskan tentang manfaat apa ini bagi pengguna? Di masa depan hipotetis ini, setiap rilis akan memiliki beberapa perubahan yang tidak relevan bagi sebagian besar pengguna, seperti sekarang. Informasi berguna apa yang akan kami sampaikan dengan menabrak angka utama setiap beberapa bulan? "Ini mungkin menghancurkan seseorang, tapi mungkin tidak menghancurkanmu"? Haruskah kita juga menabrak versi utama pada rilis perbaikan bug, mengingat keniscayaan historis bahwa sebagian besar dari mereka akan merusak kode setidaknya 1 orang? Dapatkah Anda memberikan contoh "pengembang perangkat lunak, pengguna perangkat lunak, dan manajer distribusi perangkat lunak" yang sebenarnya pernah bingung?

Perhatikan bahwa milis adalah tempat yang lebih tepat untuk diskusi ini, dan mungkin kami harus berdiskusi di sana sebelum benar-benar membuat perubahan apa pun, tetapi komentar di sini akan berguna untuk memahami jenis masalah yang Anda inginkan. untuk dibahas dalam diskusi itu.

@njsmith Tampaknya satu-satunya hal yang tidak kami setujui adalah apakah pembuatan versi semantik adalah asumsi default saat ini. Ini membutuhkan definisi yang lebih jelas tentang komunitas di mana ia (atau tidak) default. Tingkat manajemen perangkat lunak yang saya pedulikan adalah manajemen distribusi dan administrasi sistem, di mana orang memutuskan versi mana yang paling sesuai dalam konteks mereka.

Penyelidikan informal yang membawa saya pada kesimpulan bahwa pembuatan versi semantik adalah default terdiri dari berbicara dengan administrator instalasi komputasi ilmiah. Saya juga membayangkan
pendekatan yang lebih empiris (membuat daftar paket pada instalasi Debian baru-baru ini dan memilih beberapa di antaranya secara acak untuk menyelidiki pendekatan pembuatan versi mereka), tetapi ini ternyata sangat sulit, karena beberapa proyek dengan jelas menyatakan apakah mereka menggunakan versi semantik atau tidak.

Sebuah komentar dari seorang administrator sistem secara khusus menurut saya relevan: dia mengatakan bahwa untuk tujuan memutuskan versi mana yang akan diinstal, konvensi apa pun selain pembuatan versi semantik tidak berguna. Administrator sistem tidak dapat menjelajahi setiap paket secara detail (mereka kekurangan waktu dan kompetensi) atau berkonsultasi dengan semua pengguna mereka (terlalu banyak dari mereka). Mereka harus mengadopsi kebijakan yang seragam, dan ini cenderung didasarkan pada asumsi pembuatan versi semantik. Misalnya, seorang administrator dari sebuah cluster komputasi mengatakan kepada saya bahwa dia memeriksa dengan beberapa "power user" yang dia kenal secara pribadi sebelum menerapkan update dengan perubahan pada nomor versi utama.

Adapun contoh orang yang benar-benar bingung, khususnya tentang pengguna ilmiah Python, saya punya banyak dari mereka: rekan kerja di tempat kerja, orang yang saya temui di konferensi, orang yang meminta nasihat melalui email, siswa di kelas saya. Ini biasanya dimulai dengan "Saya tahu Anda adalah pakar Python, dapatkah Anda membantu saya dengan suatu masalah?" Masalah itu ternyata skrip yang berfungsi di satu komputer tetapi tidak di komputer lain. Sebagian besar dari orang-orang ini tidak mempertimbangkan masalah ketergantungan sama sekali, tetapi beberapa benar-benar membandingkan nomor versi dari kedua penginstalan, hanya menemukan "perbedaan kecil".

Seperti yang dicatat oleh @ eric-wieser dan @rgommers , permintaan saya hampir sama dengan meminta inisial "1". dihapus dari versi NumPy. Dengan kata lain, NumPy de facto sudah menggunakan versi semantik, meskipun bukan merupakan hasil dari keputusan kebijakan dan oleh karena itu mungkin tidak dilakukan secara ketat. Namun, ini menunjukkan bahwa NumPy dapat mengadopsi pembuatan versi semantik dengan hampir tidak ada perubahan pada alur kerja pengembangan saat ini.

Sebuah komentar dari seorang administrator sistem secara khusus menurut saya relevan: dia mengatakan bahwa untuk tujuan memutuskan versi mana yang akan diinstal, konvensi apa pun selain pembuatan versi semantik tidak berguna.

Sayangnya, pembuatan versi semantik juga tidak berguna untuk ini :-(. Saya tidak bermaksud untuk membelah rambut atau membesar-besarkan; Saya benar-benar mengerti bahwa ini adalah masalah yang nyata. Tetapi hanya karena suatu masalah itu nyata, bukan berarti ada solusi. Anda pada dasarnya tidak dapat menyimpulkan pertanyaan "haruskah saya meningkatkan perangkat lunak ini?" Menjadi pemeriksaan mekanis sederhana. Itu hanya fantasi. Proyek yang menggunakan semver secara teratur membuat rilis besar yang semua penggunanya harus segera meningkatkannya, dan secara teratur membuat perubahan kecil yang melanggar rilis.

Administrator sistem tidak dapat menjelajahi setiap paket secara detail (mereka kekurangan waktu dan kompetensi) atau berkonsultasi dengan semua pengguna mereka (terlalu banyak dari mereka). Mereka harus mengadopsi kebijakan yang seragam, dan ini cenderung didasarkan pada asumsi pembuatan versi semantik. Misalnya, seorang administrator dari sebuah cluster komputasi mengatakan kepada saya bahwa dia memeriksa dengan beberapa "power user" yang dia kenal secara pribadi sebelum menerapkan update dengan perubahan pada nomor versi utama.

Saya suka bagian ini :-). Saya ragu kita akan setuju tentang filosofi semver, tetapi jauh lebih mudah untuk berdiskusi tentang efek konkret dari skema pembuatan versi yang berbeda, dan hasil mana yang menurut kami paling diinginkan.

Saya tidak berpikir konsep semver ada hubungannya dengan kebijakan ini - apakah admin sistem yang Anda ajak bicara benar-benar memeriksa setiap proyek untuk melihat apakah mereka menggunakan semver? Kebanyakan proyek tidak, seperti yang Anda katakan, sulit untuk membedakan mana yang berhasil. Dan kebijakannya sama dengan yang digunakan sysadmin sejak lama bahkan sebelum semver ada. Saya pikir karakterisasi yang lebih baik dari kebijakan ini adalah: "ikuti rekomendasi proyek tentang seberapa berhati-hati dalam melakukan peningkatan", bersama dengan tradisi kuno bahwa rilis utama adalah "besar" dan rilis minor "kecil".

Rekomendasi proyek NumPy adalah bahwa administrator sistem harus meningkatkan ke rilis fitur baru, jadi yang saya ambil dari anekdot ini adalah bahwa skema penomoran kami saat ini secara akurat mengkomunikasikan apa yang kami inginkan, dan bahwa beralih ke semver tidak akan ...

@njsmith Oke, mari kita berpaling dari filosofi dan menuju kepraktisan: Apa peran nomor versi perangkat lunak dalam komunikasi antara pengembang perangkat lunak, pengelola sistem, dan pengguna perangkat lunak?

Sekali lagi tampaknya kami memiliki perbedaan pendapat yang besar di sini. Untuk Anda, para pengembanglah yang memberikan instruksi kepada pemelihara sistem dan pengguna, dan menggunakan nomor versi untuk menyampaikan instruksi mereka. Bagi saya, setiap pemain harus memutuskan sesuai dengan kriterianya, dan nomor versi harus bertindak sebagai alat komunikasi faktual di tingkat yang paling kasar.

Mengingat NumPy tidak memiliki implikasi keamanan, saya tidak melihat bagaimana dan mengapa proyek NumPy harus memberikan rekomendasi universal. Orang dan institusi memiliki kebutuhan yang berbeda. Itulah mengapa kami memiliki ArchLinux dan CentOS, dengan kebijakan pembaruan yang sangat berbeda.

@khinsen Paket oldnumeric masih berfungsi dengan sempurna, dan orang dapat menginstalnya dengan:

pip install oldnumeric

Mungkin ini bisa jadi "stable numpy" yang Anda usulkan, di mana antarmuka ke numpy dibatasi untuk Python / Cython dan tidak ada yang pernah berubah. Tentu saja, menulis kode dengan oldnumeric sangat sulit dipahami, tetapi Anda tidak bisa menggunakan keduanya.

@xoviat Benar, tapi itu masalah yang berbeda. Maksud saya di sini bukanlah pelestarian perangkat lunak, tetapi komunikasi antara pemain yang berbeda dalam manajemen perangkat lunak.

Pertanyaan: Sebagai administrator sistem (bahkan hanya di mesin pribadi Anda), apakah Anda mengharapkan sebuah paket melepaskan lapisan API lengkap dari versi 1.8 ke versi 1.9?

Bagi mereka yang menjawab "ya", pertanyaan kedua: dapatkah Anda menyebutkan perangkat lunak lain selain numpy yang pernah melakukan ini?

BTW, saya dapat meyakinkan Anda bahwa banyak orang yang digigit oleh ini, karena saya mendapat banyak surat yang menanyakan mengapa MMTK berhenti bekerja dari satu hari ke hari berikutnya. Semua orang ini telah melakukan pembaruan rutin terhadap penginstalan perangkat lunak mereka, tanpa mengharapkan konsekuensi yang serius.

Tetapi menjatuhkan oldnumeric bukanlah peristiwa terburuk dalam sejarah NumPy baru-baru ini. Kehormatan itu diberikan untuk mengubah semantik salin / tampilan dari beberapa operasi seperti diagonal . Kode yang mengembalikan hasil yang berbeda tergantung pada versi NumPy (perubahan nomor versi kecil!) Adalah mimpi buruk yang nyata.

BTW, karena hampir tidak ada yang tahu ceritanya: pip install oldnumeric berfungsi sejak dua hari lalu, karena @xoviat menyiapkan paket tambahan ini dan meletakkannya di PyPI. Terima kasih banyak!

apakah Anda mengharapkan sebuah paket untuk melepaskan lapisan API lengkap dari versi 1.8 ke versi 1.9?

Lapisan mana yang Anda maksud?

dapatkah Anda menyebutkan perangkat lunak lain selain numpy yang pernah melakukan ini?

SciPy menjatuhkan weave dan maxentropy paket, pandas merusak fitur-fitur utama secara teratur. Saya yakin ada banyak contoh yang lebih menonjol. EDIT: Python itu sendiri misalnya, lihat https://docs.python.org/3/whatsnew/3.6.html#removed

BTW, saya dapat meyakinkan Anda bahwa banyak orang yang digigit oleh ini, karena saya mendapat banyak surat yang menanyakan mengapa MMTK berhenti bekerja dari satu hari ke hari berikutnya. Semua orang ini telah melakukan pembaruan rutin terhadap penginstalan perangkat lunak mereka, tanpa mengharapkan konsekuensi yang serius.

Perubahan itu sekitar 10 tahun dalam pembuatan, dan tidak mungkin skema pembuatan versi yang berbeda akan membuat perbedaan di sini.

Menghilangkan fitur yang tidak digunakan lagi adalah pertukaran antara melanggar sebagian kecil kode (lama), dan menjaga basis kode tetap mudah dipelihara. Secara keseluruhan, jika kita melakukan kesalahan, maka kemungkinan besar kita melakukan itu di sisi konservatif. Sebagai seseorang yang juga harus berurusan dengan basis kode perusahaan besar berusia bertahun-tahun yang menggunakan numpy, saya merasakan sakit Anda, tetapi Anda memperdebatkan sesuatu yang sama sekali bukan solusi (dan secara umum tidak ada solusi lengkap; mendidik pengguna tentang hal-hal seperti menyematkan versi dan memeriksa peringatan penghentian adalah hal terbaik yang dapat kami lakukan).

Lapisan mana yang Anda maksud?

dukungan numerik / numarray saya asumsikan

@rgommers Maaf, saya seharusnya mengatakan "contoh lain di luar ekosistem SciPy".

Juga, saya tidak mengeluh tentang mencabut dukungan untuk oldnumeric . Saya mengeluh tentang melakukan ini tanpa perubahan pada nomor versi utama.

Apa bedanya hal itu? Itu akan membuat orang ragu untuk memperbarui tanpa membaca catatan rilis. Setiap orang yang menggunakan (tetapi tidak mengembangkan) kode Python akan menganggap ini sebagai tanda untuk berhati-hati.

Jangan lupa bahwa ekosistem SciPy memiliki sejumlah besar pengguna low profile yang tidak secara aktif mengikuti perkembangan. Python dan NumPy adalah item infrastruktur dengan sifat yang sama seperti ls dan gcc untuk mereka. Dan seringkali kurang dari itu: mereka menggunakan beberapa perangkat lunak yang kebetulan ditulis dengan Python dan kebetulan bergantung pada NumPy, dan ketika rusak mereka benar-benar hilang.

@rgommers Maaf, saya seharusnya mengatakan "contoh lain di luar ekosistem SciPy".

Baru saja mengedit balasan saya dengan tautan ke catatan rilis Python, yang berada di luar ekosistem SciPy.

Apa bedanya hal itu? Itu akan membuat orang ragu untuk memperbarui tanpa membaca catatan rilis. Setiap orang yang menggunakan (tetapi tidak mengembangkan) kode Python akan menganggap ini sebagai tanda untuk berhati-hati.

Ini tidak akan menjadi masalah. Jika alih-alih 1.12, 1.13, 1.14, dll. Kami memiliki 12.0, 13.0, 14.0, maka pengguna akan terbiasa dan akan menggunakan strategi peningkatan yang sama seperti sebelumnya. Sebagian besar tidak akan tiba-tiba menjadi jauh lebih konservatif.

Jangan lupa bahwa ekosistem SciPy memiliki sejumlah besar pengguna low profile yang tidak secara aktif mengikuti perkembangan. Python dan NumPy adalah item infrastruktur dengan sifat yang sama seperti ls dan gcc untuk mereka. Dan seringkali kurang dari itu: mereka menggunakan beberapa perangkat lunak yang kebetulan ditulis dengan Python dan kebetulan bergantung pada NumPy, dan ketika rusak mereka benar-benar hilang.

Semua benar, dan semua tidak dapat diperbaiki secara ajaib dengan nomor versi. Jika mereka menjalankan pip install --upgrade numpy , mereka harus tahu apa yang mereka lakukan (dan ini bahkan tidak menunjukkan nomor versi). Jika itu adalah sistem pengemasan mereka, maka mereka melihat masalah perangkat lunak yang rusak tidak memiliki rangkaian pengujian yang layak (atau yang tidak berjalan).

Kelemahan lain dari mengubah skema pembuatan versi sekarang:

• kami akan membuat perubahan dalam versi tanpa perubahan dalam kebijakan pemeliharaan, akan membingungkan daripada membantu
• kita sekarang pada dasarnya mengikuti jejak Python dan melakukan hal yang sama seperti seluruh ekosistem. itu hal yang bagus
• mungkin yang paling penting: kita akan kehilangan kemampuan untuk memberi sinyal perubahan besar yang sebenarnya. jenis yang akan kita gunakan untuk 2.x, seperti rilis yang akan mematahkan ABI.

Referensi dasar saya bukanlah Python, tetapi instalasi perangkat lunak biasa. Seperti yang saya katakan, bagi banyak (mungkin sebagian besar) pengguna, NumPy adalah infrastruktur seperti gnu-coreutils atau gcc. Mereka tidak menafsirkan nomor versi secara khusus dalam konteks ekosistem SciPy.

Saya melakukan pemeriksaan cepat pada sistem Debian 9 dengan sekitar 300 paket yang diinstal. 85% dari mereka memiliki nomor versi yang dimulai dengan bilangan bulat diikuti dengan titik. Awalan bilangan bulat yang paling umum adalah 1 (30%), 2 (26%), 0 (14%) dan 3 (13%). Jika NumPy mengadopsi skema penomoran versi yang sesuai dengan ekspektasi umum (misalnya pembuatan versi semantik atau pendekatan yang mirip), itu pasti akan menonjol dan diperlakukan dengan hati-hati.

Perhatikan juga bahwa satu-satunya pembaruan dalam perangkat lunak yang diinstal Debian yang pernah merusak banyak hal untuk saya berada di ekosistem SciPy, dengan satu-satunya pengecualian dari pembaruan Emacs yang membawa perubahan dalam mode-org yang merusak ekstensi mode-org buatan sendiri. Jadi, keseluruhan awalan nomor versi rendah tampaknya menunjukkan bahwa perangkat lunak yang paling banyak digunakan jauh lebih stabil daripada NumPy dan kawan-kawan.

Keseragaman di seluruh ekosistem SciPy memang penting, tetapi saya lebih suka seluruh ekosistem mengadopsi skema versi yang sesuai dengan harapan dunia luar. Saya hanya memulai dengan NumPy karena saya melihatnya sebagai bagian paling dasar. Ini bahkan lebih infrastruktur dari apa pun.

Akhirnya, saya menganggap perubahan dalam semantik fungsi sebagai perubahan yang jauh lebih penting daripada perubahan dalam ABI. Yang pertama dapat menyebabkan mimpi buruk debugging bagi ratusan pengguna, dan membuat program menghasilkan hasil yang salah yang tidak terdeteksi selama bertahun-tahun. Yang terakhir mengarah ke pesan kesalahan yang dengan jelas menunjukkan kebutuhan untuk memperbaiki sesuatu.

Menurut standar tersebut, NumPy bahkan tidak mengikuti jejak Python, karena satu-satunya perubahan dalam semantik yang saya ketahui dalam bahasa Python terjadi dari 2 ke 3.

Akhirnya, saya menganggap perubahan dalam semantik fungsi sebagai perubahan yang jauh lebih penting daripada perubahan dalam ABI. Yang pertama dapat menyebabkan mimpi buruk debugging bagi ratusan pengguna, dan membuat program menghasilkan hasil yang salah yang tidak terdeteksi selama bertahun-tahun. Yang terakhir mengarah ke pesan kesalahan yang dengan jelas menunjukkan kebutuhan untuk memperbaiki sesuatu.

Ini kami berusaha sangat keras untuk tidak melakukannya. Kerusakan yang jelas ketika beberapa fitur dihilangkan dapat terjadi, mengubah hasil numerik secara diam-diam seharusnya tidak. Itu satu hal yang kami pelajari dari perubahan tampilan diagonal - itu adalah kesalahan di belakang.

itu pasti akan menonjol dan diperlakukan dengan hati-hati.

Saya masih tidak setuju. Bahkan di Debian, yang jelas bukan "instalasi perangkat lunak biasa" untuk basis pengguna kami (seperti Anaconda di Windows). Anda juga tampaknya mengabaikan argumen saya di atas bahwa pengguna bahkan tidak dapat melihat nomor versi secara normal (baik dengan pip install --upgrade atau dengan manajer paket).

Juga, pengalaman Anda bahwa segala sesuatu yang lain tidak pernah rusak kemungkinan besar karena Anda menggunakan hal-hal seperti utilitas OS dan program GUI, bukan rantai ketergantungan besar lainnya. Misalnya, ekosistem JavaScript / NodeJS secara keseluruhan mungkin lebih rapuh daripada yang Python.

BTW, saya dapat meyakinkan Anda bahwa banyak orang yang digigit oleh ini, karena saya mendapat banyak mail yang menanyakan mengapa MMTK berhenti bekerja dari satu hari ke hari berikutnya

Ini adalah contoh seluk-beluk yang bagus di sini. Sejauh yang saya tahu, MMTK dan proyek Anda yang lain adalah satu-satunya yang masih ada yang terpengaruh oleh penghapusan kode kompatibilitas numerik / numarray. Berapa banyak pengguna yang Anda perkirakan akan Anda miliki? 100? 1000? NumPy memiliki jutaan, jadi mungkin 0,1% pengguna kami terpengaruh oleh penghapusan ini? Ini jelas bukan nol, dan fakta bahwa itu kecil tidak berarti itu tidak masalah - Saya berharap kami dapat mendukung 100% pengguna selamanya dengan segala cara. Dan saya memahami bahwa ini sangat menyakitkan bagi Anda, menerima 100% keluhan dari pengguna Anda.

Tetapi jika kami menabrak nomor versi utama kami untuk ini, itu berarti 99,9% pengguna kami, kami baru saja menangis. Itu positif palsu. OTOH untuk 0,1% pengguna itu, itu sangat penting. Namun tidak jarang kami merusak lebih dari 0,1% pengguna dalam rilis mikro , terlepas dari upaya terbaik kami. Jadi apa yang kita lakukan?

Sangat tidak mungkin untuk mengkomunikasikan nuansa ini melalui instrumen tumpul dari nomor versi. Semua orang menginginkan cara cepat untuk mengetahui apakah peningkatan versi akan merusak kode mereka, untuk alasan yang bagus. Semver populer karena menjanjikan untuk melakukan itu. Sangat populer untuk alasan yang sama yang populer untuk berpikir bahwa diet iseng dapat menyembuhkan kanker. Saya berharap semver memenuhi janjinya juga. Namun ternyata tidak, dan jika kita ingin menjadi insinyur yang baik, kita perlu menghadapi kompleksitas dari kenyataan itu.

Saya tidak mengerti bagaimana dan mengapa proyek NumPy harus memberikan rekomendasi universal. Orang dan institusi memiliki kebutuhan yang berbeda.

Kami memberikan rekomendasi universal karena kami hanya memiliki 1 nomor versi, jadi menurut definisi apa pun yang kami lakukan dengannya adalah rekomendasi universal. Itu bukanlah sesuatu yang dapat kami kendalikan.

Kehormatan itu diberikan untuk mengubah semantik salin / tampilan dari beberapa operasi seperti diagonal .

IIRC Kami benar-benar tidak menerima satu keluhan pun tentang hal ini dari seseorang yang mengatakan bahwa itu melanggar kode mereka. (Mungkin satu orang?) Saya tidak mengatakan itu berarti tidak ada yang terpengaruh, jelas orang yang mengeluh tentang perubahan pada umumnya hanya sebagian kecil dari mereka yang terpengaruh, tetapi jika Anda menggunakan keluhan sebagai proxy kasar untuk nyata- dampak dunia maka saya tidak berpikir ini membuat 50 besar.

Dan BTW, saya cukup yakin jika Anda menelusuri riwayat yang mendalam, Anda dapat menemukan perubahan yang jauh lebih mengerikan daripada itu :-).

Perhatikan juga bahwa satu-satunya pembaruan dalam perangkat lunak yang diinstal Debian yang pernah merusak banyak hal untuk saya berada di ekosistem SciPy, dengan satu-satunya pengecualian dari pembaruan Emacs yang membawa perubahan dalam mode-org yang merusak ekstensi mode-org buatan sendiri.

Hormat saya, saya pikir ini menjelaskan lebih banyak tentang bagaimana Anda menggunakan NumPy vs Debian daripada tentang NumPy versus Debian. Saya suka Debian, saya telah menggunakannya selama hampir 20 tahun sekarang, dan saya tidak dapat menghitung berapa kali barang rusak itu. Baru minggu lalu, beberapa masalah aneh dengan gnome baru merusak skrip login saya dan beberapa peningkatan lainnya merusak trackpoint saya . (Keduanya sudah diperbaiki sekarang, tapi tetap saja.) Saya juga akan mencatat bahwa emacs Debian diatur untuk mengunduh dan menjalankan kode melalui saluran yang tidak terenkripsi / tidak aman selama bertahun-tahun, karena masalah kompatibilitas mundur tentang mengaktifkan pemeriksaan keamanan. Menurut saya tidak ada yang namanya rilis gcc yang tidak merusak beberapa orang, jika hanya karena orang melakukan hal-hal seperti menggunakan -Werror dan kemudian perubahan kecil dalam perilaku peringatan (yang dapat mengandalkan interaksi antara proses pengoptimalan, dll.) menjadi perubahan yang mengganggu.

Jadi, keseluruhan awalan nomor versi rendah tampaknya menunjukkan bahwa perangkat lunak yang paling banyak digunakan jauh lebih stabil daripada NumPy dan kawan-kawan.

Keseluruhan awalan nomor versi rendah adalah karena perangkat lunak yang paling banyak digunakan tidak menggunakan semver.

Akhirnya, saya menganggap perubahan dalam semantik fungsi sebagai perubahan yang jauh lebih penting daripada perubahan dalam ABI. Yang pertama dapat menyebabkan mimpi buruk debugging bagi ratusan pengguna, dan membuat program menghasilkan hasil yang salah yang tidak terdeteksi selama bertahun-tahun. Yang terakhir mengarah ke pesan kesalahan yang dengan jelas menunjukkan kebutuhan untuk memperbaiki sesuatu.

Ya, itulah mengapa kami sangat waspada dengan perubahan semacam itu.

Ada beberapa keterputusan dalam perspektif di sini: Anda tampaknya berpikir bahwa kami mengubah hal-hal mau tak mau sepanjang waktu, tidak peduli tentang kompatibilitas ke belakang, dll. Saya dapat menghargai itu; Saya mengerti itu mencerminkan pengalaman Anda. Namun menurut pengalaman kami, kami sangat berhati-hati dalam perubahan tersebut, dan saya akan mengatakan bahwa ketika saya berbicara dengan pengguna, ~ 5% yang memiliki perspektif Anda, dan ~ 95% yang merasa bahwa numpy melakukan pekerjaan yang baik dengan stabilitas, atau bahwa melakukan pekerjaan yang terlalu baik dan harus lebih rela untuk merusak sesuatu. Mungkin Anda bisa terhibur mengetahui bahwa meskipun kami mengecewakan Anda, kami juga mengecewakan grup terakhir itu :-).

dengan satu-satunya pengecualian dari pembaruan Emacs

Nah, untuk keluar dari topik, itu berfungsi sebagai contoh sisi lain dari stabilitas. Emacs statis selama bertahun-tahun karena penolakan Stallman untuk berubah, dan itu menghasilkan percabangan xEmacs. Jalan saya sendiri pergi ke Emacs -> xEmacs, untuk memastikannya, -> Vim;) Fosilisasi dini juga mengapa saya berhenti menggunakan Debian saat itu. Untuk beberapa hal, perubahan tidak diperlukan atau bahkan diinginkan, dan saya berharap ada orang yang menjalankan versi lama BSD pada perangkat keras lama yang tersembunyi di dalam lemari. Tetapi saya tidak berharap ada banyak tempat seperti itu.

Menyangkut masalah saat ini, menurut saya perubahan dalam skema pembuatan versi tidak akan membuat perbedaan apa pun. Jalan yang lebih produktif mungkin untuk mengatasi masalah modernisasi. @khinsen Apakah Anda mengerti cara untuk menerima pembaruan proyek utama Anda? Jika demikian, saya pikir kita harus mencari cara untuk membantu Anda melakukannya.

Saya mencoba memperbarui proyek di
https://github.com/ScientificPython. Itu membutuhkan pembaruan kode Python itu
menggunakan C API lama (dan maksud saya lama; beberapa fungsi seperti Py_PROTO dulu
dari 2000). PR tentu saja diterima, tapi saya tidak yakin apakah ada orang
ingin menghabiskan waktu mereka untuk itu.

Masalah yang lebih besar yang menurut saya dia kemukakan adalah bahwa ada "banyak
proyek "(Saya tidak tahu persis di mana mereka karena semua proyek
yang saya lihat mendukung Python 3) yang juga perlu diperbarui; bagaimana itu
menentukan proyek mana yang dialokasikan waktu pengembang NumPy? Dan juga saya
jangan berpikir klaim utamanya tidak valid: SciPy sangat diuntungkan dari
fakta bahwa itu bisa dengan mudah menyalin dan menempel proyek fortran lama (seperti
fftpack) dengan sedikit atau tanpa modifikasi. Jika ini telah ditulis katakan
"fortran 2" dan kompiler baru hanya mengkompilasi "fortan 3", pasti ada
menjadi masalah penting.

Meskipun demikian, masalah ini sebenarnya bukan kesalahan NumPy. Terlepas dari apa yang dia miliki
berkata, dengan NumPy 1.13 terpasang, numerik lama masih lulus semua tes,
menunjukkan bahwa NumPy bukanlah pelakunya di sini. Sejak API numerik lama
secara harfiah lebih dari satu dekade (mungkin mendekati dua dekade!), dan itu masih
bekerja pada NumPy terbaru, menurut saya NumPy API mungkin stabil
cukup.

@charris Saya sepenuhnya setuju dengan Anda bahwa "tidak pernah mengubah apa pun" bukanlah sikap produktif dalam komputasi.

Maksud saya adalah bahwa ekosistem SciPy telah menjadi sangat populer sehingga tidak ada pendekatan tunggal untuk mengelola perubahan yang cocok untuk semua orang. Itu tergantung pada seberapa cepat metode dan implementasinya berkembang di bidang tertentu, pada kompetensi teknis praktisi, pada perangkat lunak lain yang mereka andalkan, pada sumber daya yang dapat mereka investasikan ke dalam kode, dll.

Tim inti NumPy saat ini lebih peduli tentang kemajuan (ke arah yang penting untuk beberapa bidang tetapi sebagian besar tidak relevan dengan yang lain) daripada tentang stabilitas. Tidak apa-apa - di dunia Open Source, orang yang melakukan pekerjaan memutuskan apa yang ingin mereka kerjakan. Namun kesan saya adalah mereka tidak menyadari bahwa banyak orang yang pekerjaannya bergantung pada NumPy memiliki kebutuhan yang berbeda, merasa ditinggalkan oleh tim pengembang, dan mulai beralih dari SciPy menuju teknologi yang lebih tradisional dan stabil seperti C dan Fortran ( dan, dalam satu kasus saya tahu, bahkan ke Matlab).

Saya tidak tahu berapa persentase pengguna NumPy yang cukup tidak senang dengan keadaan saat ini, dan saya rasa orang lain tidak memilikinya. Setelah paket perangkat lunak menjadi infrastruktur, Anda tidak dapat dengan mudah memperkirakan siapa yang bergantung padanya. Banyak yang bahkan tidak menyadarinya, dan banyak kode yang bergantung pada NumPy (secara langsung atau tidak langsung) tidak publik dan / atau tidak mudah ditemukan.

Jika kami ingin membuat semua orang senang di komunitas SciPy, kami perlu menemukan cara untuk menangani beragam kebutuhan. Langkah pertama, menurut pendapat saya, adalah mengalihkan kontrol atas laju perubahan dalam instalasi tertentu dari pengembang ke seseorang yang lebih dekat dengan pengguna akhir. Bisa jadi pengguna akhir itu sendiri, atau administrator sistem, atau pembuat paket, atau siapa pun - sekali lagi saya rasa tidak ada jawaban universal untuk pertanyaan ini. Apa yang dibutuhkan dari pengembang adalah informasi di tingkat yang tepat, dan itulah mengapa saya memulai utas ini. Tentu saja nomor versi tidak dapat menyelamatkan dunia, tetapi saya melihatnya sebagai langkah pertama untuk membangun tanggung jawab terdistribusi untuk manajemen perubahan.

Akhirnya, beberapa dari Anda tampaknya percaya bahwa saya bertengkar secara pribadi tentang kode saya sendiri. Mungkin akan mengejutkan Anda bahwa sikap pribadi saya bukanlah yang saya bela di sini. Sweetspot saya sendiri untuk tingkat perubahan berada di antara apa yang umum di bidang saya dan apa yang dianggap lazim di tim NumPy. Sebagian besar pekerjaan saya hari ini menggunakan Python 3 dan NumPy> 1.10. MMTK berusia 20 tahun dan saya melakukan banyak hal dengan cara berbeda hari ini. Cukup sering saya mengambil potongan kode dari MMTK yang saya perlukan untuk proyek tertentu dan menyesuaikannya dengan "SciPy modern", tetapi itu adalah sesuatu yang dapat saya lakukan dengan percaya diri hanya karena saya menulis kode aslinya.

Saya telah mempertahankan MMTK yang stabil sebagai layanan untuk komunitas, bukan untuk penggunaan saya sendiri, yang menjelaskan mengapa saya melakukan pemeliharaan dengan cara minimalis, menghindari perubahan skala besar dalam basis kode. Baik pendanaan untuk pengembang perangkat lunak dan domain-kompeten sangat sulit ditemukan, jadi MMTK selalu menjadi proyek satu-pengelola-plus-kontributor-sesekali. Saya bahkan tidak yakin bahwa mem-port semua MMTK ke "SciPy modern" akan bermanfaat bagi siapa pun, karena banyak kode yang bergantung pada MMTK sama sekali tidak terawat. Tapi kemudian, itu benar untuk sebagian besar kode Python yang saya lihat di sekitar saya, bahkan kode sama sekali tidak terkait dengan MMTK. Ini adalah realitas domain penelitian di mana eksperimen daripada komputasi dan pengkodean menjadi fokus perhatian.

@xoviat Jumlah tes di oldnumeric sangat kecil. Saya tidak akan menyimpulkan banyak dari fakta bahwa mereka lulus dengan NumPy 1.13.

Modul ekstensi C yang Anda lihat benar-benar berusia 20 tahun dan ditulis untuk Python 1.4. Saat itu, itu adalah salah satu contoh combo Python-C yang paling canggih dan pada kenyataannya membentuk pengembangan awal Numeric (pre-NumPy) dan bahkan CPython sendiri: CObjects (pre-Capsules) diperkenalkan berdasarkan kebutuhan ScientificPython dan MMTK .

Saya orang pertama yang mengatakan bahwa API dan alat pendukung saat ini jauh lebih baik, dan saya berharap mereka masih akan meningkat di masa mendatang. Tetapi beberapa orang hanya ingin menggunakan perangkat lunak untuk melakukan penelitian, tidak peduli seberapa kuno itu, dan saya pikir mereka juga berhak untuk hidup.

@rgommers Saya tidak mengabaikan argumen Anda bahwa pengguna bahkan tidak bisa melihat nomor versi. Ini tidak benar untuk lingkungan yang saya lihat digunakan orang di sekitar saya. Orang-orang yang memutuskan tentang pembaruan (yang tidak selalu pengguna akhir) melihatnya. Mereka tidak hanya melakukan "pip install --upgrade" sekali seminggu. Mereka bahkan akan menganggap ini sebagai sikap ceroboh.

Jika orang-orang di sekitar terutama menggunakan Anaconda di bawah Windows, itu hanya menegaskan bahwa kami bekerja di lingkungan yang sangat berbeda. Di era keberagaman, saya berharap kita dapat menyetujui bahwa setiap komunitas dapat mengadopsi alat dan konvensi yang bekerja dengan baik untuknya.

Dan ya, NodeJS lebih buruk, saya setuju. Untungnya, saya dapat dengan mudah mengabaikannya.

Baru saja mendapat email dari seorang kolega yang mengikuti utas ini tetapi tidak berani menyela. Dengan analogi yang sangat bagus:

"Saya senang jika saya mendapat kesempatan untuk membeli mikroskop baru dan melakukan sains yang lebih baik dengannya. Tapi saya tidak suka melihat seseorang mengganti mikroskop saya dalam semalam tanpa berkonsultasi dengan saya."

Ini semua tentang memiliki kendali atas alat seseorang.

Saya berjanji tidak akan pernah masuk ke lab rekan Anda di tengah malam dan meningkatkan numpy mereka. Saya bahkan tidak memiliki balaclava .

Orang-orang yang memutuskan tentang pembaruan (yang tidak selalu pengguna akhir) melihatnya. Mereka tidak hanya melakukan "pip install --upgrade" sekali seminggu. Mereka bahkan akan menganggap ini sebagai sikap ceroboh.

Jika mereka sysadmin dan memahami pro dan kontra dari berbagai metode penginstalan, maka mereka juga harus memahami (atau diajarkan) cara kerja versi di dunia Python (dan banyak proyek perangkat lunak lain yang juga tidak menggunakan semver yang ketat).

Tim inti NumPy saat ini lebih peduli tentang kemajuan (ke arah yang penting untuk beberapa bidang tetapi sebagian besar tidak relevan dengan yang lain) daripada tentang stabilitas.

Maaf, tapi ini hanya menunjukkan bahwa Anda belum mengikuti perkembangan NumPy sama sekali dalam beberapa tahun terakhir, atau memiliki satu set kacamata yang sangat khusus. NumPy sebenarnya adalah proyek yang sangat sulit untuk dikontribusikan, karena ada banyak perhatian untuk kompatibilitas ke belakang. Itulah salah satu alasan utama kami kesulitan menarik pengelola baru.

dan, dalam satu kasus saya tahu, bahkan ke Matlab

Matlab terkenal karena merusak kompatibilitas. Hal pertama yang dilakukan proyek kerja sama yang menggunakan Matlab adalah menentukan versi yang harus digunakan setiap orang, sama dengan Microsoft Word jika digunakan untuk dokumentasi. Saya tahu orang-orang yang beralih ke NumPy justru untuk kompatibilitas yang ditingkatkan. Matlab memiliki keutamaannya, tetapi kompatibilitas bukanlah / bukan salah satunya. Mungkin banyak hal telah berubah?

Namun, saya pikir ada beberapa hal yang dapat kami lakukan ke depan yang mungkin membantu kompatibilitas. Hubungan pertama dengan diskusi NEP saat ini. Sekarang karena NumPy sudah lebih matang, mungkin merupakan ide yang baik untuk lebih banyak menggunakan NEP ketika perubahan yang mempengaruhi kompatibilitas diajukan, terutama jika NEP lebih bersifat publik dan dapat dicari. Kedua, kami dapat mencoba memasang roda untuk versi NumPy yang lebih lama di PyPI jika itu tidak terlalu berhasil. Penggunaan lingkungan virtual tampaknya menjadi ide terbaik saat ini untuk mendapatkan reproduktifitas, dan memiliki pilihan roda yang lebih luas untuk diunduh mungkin bisa membantu.

Kedua, kami dapat mencoba memasang roda untuk versi NumPy yang lebih lama di PyPI jika itu tidak terlalu berhasil.

Berkat upaya @ matthew-brett, sepertinya status saat ini adalah Windows kembali ke 1.10 , MacOS kembali ke 1.5 (kecuali 1.7 hilang ), dan Linux kembali ke 1.6 .

Situasi MacOS / Linux tampaknya cukup masuk akal. Saya kira kita bisa mengisi ulang lebih banyak rilis Windows? OTOH pip install di Windows tidak pernah berfungsi tanpa upaya heroik, jadi saya tidak yakin ada banyak audiens untuk ini. Kami sudah memiliki nilai 2 tahun, dan itu akan tumbuh seiring waktu.

Juga, terakhir kali kami mengunggah roda lama, seseorang marah kepada kami karena alur kerjanya berasumsi bahwa tidak ada roda dan kompatibilitas mundur untuk mereka rusak :-)

Akan sangat senang mendengar cerita itu.

Bukan berarti saya benar-benar mengetahui hal ini dengan baik, tetapi saya kira kami dapat mencoba untuk meningkatkan hal-hal (saya tidak begitu yakin apa artinya itu!), Kenyataannya adalah, kita perlu bergerak maju perlahan dan kecuali untuk kemungkinan beberapa kesalahan semua rilis dimaksudkan untuk memecahkan kode orang sangat sedikit. Saya pikir rilis kecil kami berarti "hampir semua orang harus memperbarui dan dapat memperbarui tanpa memperhatikan apa pun", dan saya terus terang percaya itu benar. (Jelas ada hal-hal yang mempengaruhi banyak orang seperti depresiasi bilangan bulat, tetapi tidak membuat hasil yang salah dan lama dalam pembuatan)

Saya dapat melihat bahwa mungkin ada beberapa perubahan yang cukup besar untuk menjamin peningkatan versi mayor, meskipun terus terang saya tidak yakin mana yang akan terjadi. Dan ya, mungkin ada beberapa kehilangan momentum historis dalam hal rilis utama.

Bagaimanapun saya juga tidak bisa mengatakan bahwa saya adalah penggemar yang mengatakan (hampir) setiap rilis adalah rilis utama. Saya mengerti bahwa kami mungkin telah membuat marah orang dengan beberapa perubahan, tetapi saya telah mengambil bagian dari beberapa perubahan yang agak luas dan setiap kali setelah menjelaskan alasan saya hanya mendengar bahwa itu adalah hal yang benar untuk dilakukan, dan juga kami telah menunggu tahun sampai perubahan ini berlaku.

Adapun gcc, dll. Sebagai contoh, saya tidak tahu banyak tentang kompilasi / C ++, saya merasa terganggu oleh gcc 4.8 atau lebih mulai memaksa saya untuk mencari cara mengubah flag dengan benar karena beberapa fitur C ++ 11 atau jadi seperti yang diharapkan, yang menyebabkan reaksi yang sangat mirip dengan email yang Anda terima tentang numpy, jadi saya tidak yakin ini jauh berbeda :).

Bagaimanapun, saya tidak ingin membahas terlalu banyak di sini, saya menghargai umpan balik tentang apakah kita mungkin terlalu cepat atau tidak cukup berhati-hati, tetapi saya harus mengakui bahwa saya juga tidak terlalu melihat bahwa mengubah versi utama akan banyak membantu bahwa. Secara pribadi saya berpikir bahwa 1.13 dan 1.6 adalah setidaknya satu versi utama terpisah dalam beberapa hal, tetapi tidak ada rilis tunggal di antaranya yang dapat saya tunjukkan dan katakan: itu adalah jeda kompatibilitas utama bagi banyak pengguna.
Saya ingat membaca komentar dalam kode: "Ayo lakukan ini di Numpy 2 mungkin", tepatnya karena takut ada yang melanggar sama sekali, dengan pendekatan itu saya khawatir numpy akan banyak macet, dan terus terang saya sedikit bangga menjadi bagian dari apa yang bagi saya setidaknya tampak seperti fase yang lebih aktif lagi yang dibutuhkan dan yang akan sulit jika kita bahkan lebih konservatif. (Saya mungkin bias karena saya tidak tahu apa yang terjadi sebelum saya datang :)).

Maaf, mungkin ini tidak masuk akal (kami baru saja mengadakan pesta natal). Proposal semver masuk akal, tapi harus saya akui tidak terasa seperti solusi nyata. Saya setuju dengan mencoba menaikkan versi mayor secara lebih agresif, tetapi saya juga tidak setuju dengan menyebut pada dasarnya setiap rilis sebagai rilis mayor. Saya juga setuju dengan mencoba menjadi lebih konservatif dalam beberapa kasus, tetapi saya terus terang tidak begitu yakin apa itu (hitung saja jumlah PR yang menggantung, karena tidak ada yang yakin apakah itu mungkin merusak kompatibilitas di suatu tempat;), saya yakin itu apakah porsi yang bagus)?

Dan bahkan jika saya telah membaca keluhan, jika Anda membawa sedikit gangguan dan desakan, bukan berarti kami tidak akan membatalkan setiap perubahan jika memungkinkan atau setidaknya menundanya selama satu tahun atau lebih. Saya akan mengatakan itu adalah bagian dari mengapa kami memilih model tata kelola konservatif….

Jadi setelah mengoceh begitu lama:

• "Hampir tidak ada kode yang rusak" sepertinya OK untuk versi minor?
• Kami harus bergerak maju perlahan?
• Hal-hal pada akhirnya akan rusak, dan mungkin kami terkadang dapat menaikkan versi utama. Bahkan mungkin mencoba melakukan beberapa jenis FutureWarning yang berubah lebih banyak di versi utama. (Terus terang saya tidak percaya itu akan membantu, tetapi saya bersedia mencoba)

Yang terpenting: Saya tahu frustrasinya, tetapi adakah solusi nyata untuk kita? Menurut Anda, apakah jika kami menaikkan versi utama secara agresif, Anda akan mendapatkan lebih sedikit email?

@xoviat apakah kamu menanyakan cerita tentang mendapatkan keluhan karena mengunggah roda untuk versi lama? Itu # 7570.

Definisi favorit saya tentang semver (bahwa saya tidak dapat lagi menemukan tautan ke postingan asli):

• mayor: kami sengaja merusak kode pengguna
• minor: kami tidak sengaja merusak kode pengguna
• patch: kami merusak solusi pengguna ke bug rilis minor terakhir

yang agak kurang ajar, tapi menurut saya ada hal yang penting, _any_ perubahan perilaku akan merusak beberapa pengguna di suatu tempat. Ini terutama benar dengan proyek yang memiliki permukaan API yang besar.

Langkah pertama, menurut pendapat saya, adalah mengalihkan kontrol atas laju perubahan dalam instalasi tertentu dari pengembang ke seseorang yang lebih dekat dengan pengguna akhir.

Saya pikir sesuatu yang hilang dari percakapan ini adalah bahwa versi lama pustaka selalu tersedia (pada pypi dari sumbernya) jadi jika Anda memiliki kode yang memerlukan versi lama python / numpy / matplotlib maka gunakan versi yang lebih lama. Lingkungan ruang pengguna membuat ini tidak terlalu buruk untuk dikelola.

Jika Anda ingin menggunakan versi baru dari perpustakaan maka Anda harus membayar biaya untuk mengikuti perubahan tersebut. Untuk mendorong analogi mikroskop, Anda harus melakukan perawatan rutin pada mikroskop Anda atau mikroskop itu menurun seiring waktu; perangkat lunak tidak berbeda.

@njonk Itu cukup lucu. IMO # 7570 bukanlah masalah yang valid mengingat itu
NumPy memenuhi spesifikasi roda manylinux. Umumnya roda
harus diunggah untuk versi yang lebih lama, dengan asumsi waktu itu gratis. Diberikan
saat itu tidak ada waktu luang, kami hanya dapat mencatat bahwa orang dapat membuat roda
untuk versi NumPy tertentu jika mereka menginginkannya; mengirimkan PR ke
repositori roda-numpy. Atau tidak.

@xoviat Maksud saya, jika sistem mereka rusak, maka rusak; bisa menunjukkan spesifikasi tidak benar-benar mengubah itu. Secara umum dalam diskusi ini saya pikir kita harus lebih peduli tentang efek aktual pada pengguna akhir daripada kemurnian teoritis. Tapi OTOH dalam hal ini saya pikir itu adalah panggilan yang tepat untuk menjaga roda tetap tinggi, mengingat mereka sudah mengatasi masalah tersebut, roda sudah diunggah, dan sejauh yang kami tahu ada lebih banyak orang yang mendapat manfaat daripada mengalami masalah. Tapi ini adalah pengingat yang menarik tentang betapa halusnya "ketidakcocokan ke belakang", dan betapa sulitnya membuat aturan umum.

@njsmith Peran Anda dalam analogi mikroskop adalah sebagai penjual mikroskop yang mendekati direktur lab kolega saya dengan tawaran untuk mengganti semua mikroskop lab dengan model terbarunya, menyembunyikan kalimat "tidak sesuai dengan sampel yang tebalnya lebih dari 1mm" dalam tulisan kecil dari kontrak. Hal ini menyulitkan direktur lab untuk memahami bahwa ada poin teknis yang perlu didiskusikan dengan orang yang memahami detail tersebut.

@rgommers Saya mengerti bahwa mempertahankan NumPy adalah tugas, dan sebenarnya saya akan menangani perubahan secara berbeda terutama karena alasan itu jika saya yang bertanggung jawab. Saya akan meletakkan kode saat ini dalam mode pemeliharaan minimal dan mulai mendesain ulang besar di namespace yang berbeda, membiarkan lama dan baru hidup berdampingan tanpa batas dengan interoperabilitas melalui antarmuka buffer. Dan ya, saya tahu ini bukan upaya sepele karena banyak alasan, tetapi menurut saya ini satu-satunya cara untuk keluar dari tumpukan hutang teknis yang menumpuk. Tujuan utama dari desain ulang ini adalah kemudahan perawatan.

Di sisi lain, saya pasti mengakui memiliki satu set kacamata yang sangat khusus, tetapi itu berlaku untuk semua orang dalam diskusi ini. Kacamata saya adalah kacamata "komputasi ilmiah tradisional", yang merupakan lingkungan kerja saya. Garis dasar (ekspektasi default) adalah bahwa pembaruan tidak pernah merusak apa pun dengan sengaja. Itu kebijakan bahasa standar (C, Fortran) tetapi juga perpustakaan infrastruktur (BLAS, LAPACK, MPI, ...). Inovasi tetap terjadi (misalnya ATLAS). Jika menurut Anda itu konservatif, izinkan saya menjelaskan apa arti konservatif di dunia saya: jangan pernah menginstal versi apa pun yang tidak berusia setidaknya dua tahun, untuk memastikan bahwa sebagian besar bug diketahui. Itu adalah kebijakan umum untuk superkomputer yang waktunya sangat mahal, dan hasilnya hampir tidak dapat diperiksa karena alasan itu.

Perhatikan bahwa saya tidak mengatakan bahwa NumPy harus mengadopsi ekspektasi default dunia saya. Saya hanya mengatakan itu harus dengan jelas menandakan bahwa itu berbeda.

@seberg "Hampir tidak ada kode yang rusak" tampaknya baik-baik saja dalam teori untuk versi minor. Tetapi begitu perangkat lunak memperoleh status infrastruktur (dan menurut saya, NumPy berada pada level itu), tidak mungkin memperkirakan berapa banyak pengembang dan pengguna yang dapat terpengaruh. Kriteria itu kemudian selalu menjadi "hampir tidak ada orang yang saya pikir terpengaruh", dan itu tidak bagus.

@tacaswell Menurut saya perbedaan antara "sengaja" dan "secara tidak sengaja" sangat penting dalam praktiknya. Itu mempengaruhi sikap setiap orang terhadap perubahan. Lihat saja aspek kehidupan lainnya. Jika perbedaannya tidak penting, kita bisa menghilangkan kata "hati-hati" dari bahasa Inggris.

Yah, sejujurnya saya pikir gagasan "pembangunan kembali besar" cukup banyak ditinggalkan sekarang karena akan membutuhkan lebih banyak kekuatan pengembangan dan kemudian dapat menciptakan jenis kekacauan yang sama sekali berbeda (lihat py2 dan py3 untuk beberapa tahun pertama)?

Setuju, numpy adalah infrastruktur, tetapi saya bukan penggemar hanya bertindak seolah-olah melanggar lebih banyak kode orang tidak masalah / niat dengan menabrak versi utama lebih cepat adalah solusi. Rasanya lebih seperti melepaskan tugas untuk mencoba yang terbaik untuk melakukan rilis "hampir tidak ada kode yang rusak" (mungkin dengan pengecualian "kecuali Anda belum melihat peringatan untuk beberapa rilis"), kemudian benar-benar membantu dalam pengambilan keputusan memperbarui.

Jadi, kadang-kadang kita mungkin harus mengakui bahwa itu mungkin tidak benar, tetapi jika tidak, saya lebih suka mendapatkan solusi untuk memastikan bahwa kita tidak merusak lebih banyak. Tentu saja Anda menawarkan solusi (menjadi sangat konservatif dan memulai numpy 2 dengan perombakan besar-besaran), tetapi begitu kami mengakui bahwa solusi ini tidak dapat dilakukan tanpa dana besar atau lebih, apa lagi yang dapat kami lakukan?

Atau izinkan saya memperjelas: Jika Anda mengenal seseorang yang mampu mengikuti dev numpy yang dapat mengawasi agar lebih konservatif bila perlu, Anda tahu saya setidaknya menghargainya. Tapi saya pribadi tidak menghargai menyerahkan kemajuan kami setidaknya perlahan-lahan menyingkirkan beberapa sudut gelap di numpy untuk memungkinkan pengembangan di masa depan. Paling-paling, kita akan berakhir dengan NumPy mati dan pengganti dalam beberapa tahun, paling buruk kita hanya akan berakhir dengan kecepatan dan downstream menjadi frustrasi karena tidak bisa bergerak maju dan mungkin "pengganti" bermunculan, yang secara alami jika tidak terlalu dewasa hanya memperburuk keadaan.

Saya harus setuju dengan @seberg tentang membuat namespace yang berbeda. Itu
seluruh asumsi di balik ide ini adalah bahwa proyek NumPy memiliki keterbatasan
bakat dan sumber daya untuk memelihara perpustakaan yang berfungsi untuk semua orang.
Namun, bukan itu masalahnya. Pengembang tidaklah sempurna, begitu biasanya
lakukan kesalahan pertama kali. Orang yang menulis kode Numerik asli
tidak bisa memprediksi semua skenario yang akan digunakan, dan mereka
tidak bisa memprediksi munculnya implementasi alternatif, seperti PyPy.

Menurut saya, stabilitas API sangat penting. Saya juga berpikir bahwa NumPy punya
umumnya sudah benar. Faktanya adalah bahwa NumPy sudah ada
sulit untuk bernalar (dan seharusnya, mengingat bahwa setiap ons terakhir
kinerja itu penting), tetapi membuat namespace yang berbeda akan membuatnya berhasil
sangat sulit untuk menyimpan semua implikasi dari perubahan kode
kepalamu. Saya pikir sangat mungkin jika NumPy melakukan itu, akan ada
menjadi lebih banyak bug secara signifikan karena pengembang tidak memahami
konsekuensi dari mengubah kode dalam satu antarmuka di antarmuka lainnya.

Singkatnya, saya benar-benar memahami frustrasi orang. Tapi sebagai @njsmith
Dikatakan, tidak ada solusi untuk masalah yang akan memuaskan setiap pengguna.
Hanya ada solusi yang akan memuaskan sebagian besar pengguna sepanjang waktu. Dan
kenyataannya adalah bahwa jika NumPy menjadi kaki tangan minoritas pengguna (tidak dimaksudkan
dengan cara yang merendahkan) yang menuntut stabilitas API di atas segalanya, file
NUMFOKUS pendanaan mungkin mengering karena tidak jelas berapa uangnya
digunakan untuk itu, lalu di mana kita akan berada? Mungkin dalam situasi di mana
MMTK tidak dapat lagi bergantung pada NumPy, seperti situasi yang memungkinkannya
tidak lagi bergantung pada Numerik.

Saya akan meletakkan kode saat ini dalam mode pemeliharaan minimal dan mulai mendesain ulang besar di namespace yang berbeda, membiarkan lama dan baru hidup berdampingan tanpa batas dengan interoperabilitas melalui antarmuka buffer. Dan ya, saya tahu ini bukan upaya sepele karena banyak alasan, tetapi menurut saya ini satu-satunya cara untuk keluar dari tumpukan hutang teknis yang menumpuk. Tujuan utama dari desain ulang ini adalah kemudahan perawatan.

Sebenarnya saya setuju dengan Anda, tetapi saya tidak melihat bagaimana hal itu dapat dilakukan tanpa suntikan dana / visi yang besar. NumPy merupakan pekerjaan yang sangat besar. Mungkin @teoliphant dan @skrah akan melakukannya dengan janji , tetapi itu akan menjadi perjuangan yang berat.

Mengingat NumPy yang kami miliki saat ini, saya pikir kami melakukan sebaik yang dapat kami lakukan.

Bagi mereka yang menjawab "ya", pertanyaan kedua: dapatkah Anda menyebutkan perangkat lunak lain selain numpy yang pernah melakukan ini?

django adalah perangkat lunak penting lainnya yang tidak menggunakan pembuatan versi semantik. Mereka menggunakan perubahan besar untuk menunjukkan jeda substansial, tetapi menghentikan hal-hal dalam perubahan .x setelah periode peringatan yang lama. Lebih atau kurang seperti NumPy.

Saya sebenarnya setuju dengan Anda,

@shoyer karena tertarik, kenapa? Bagaimana itu tidak berubah menjadi transisi seperti py3k yang sangat menyakitkan ke basis kode baru di beberapa titik?

Itu kebijakan bahasa standar (C, Fortran) tetapi juga perpustakaan infrastruktur (BLAS, LAPACK, MPI, ...). Inovasi tetap terjadi (misalnya ATLAS).

Inovasi dengan kecepatan LAPACK / ATLAS / OpenBLAS adalah resep untuk NumPy menjadi tidak relevan jauh lebih cepat daripada yang seharusnya.

Lihat, harus jelas bagi Anda dari semua tanggapan bahwa perubahan versi ini tidak akan terjadi, dan itulah konsensus antara ~ 7 pengembang inti aktif ditambah beberapa pengembang proyek hilir besar. Jika Anda membutuhkan stabilitas mutlak, maka Anda mungkin lebih baik hanya dengan menyematkan versi tetap pada sistem Anda selama beberapa tahun, dan mendidik sysadmin Anda tentang itu.

Bagaimana itu tidak berubah menjadi transisi seperti py3k yang sangat menyakitkan ke basis kode baru di beberapa titik?

Perbedaan besar adalah bahwa Python 3 adalah tombol all / nothing (untuk program Python), mudah atau setidaknya dapat dilakukan untuk mencampur / mencocokkan pustaka ndarray yang berbeda. Antarmuka buffer berarti Anda dapat mentransfer data bolak-balik tanpa salinan. Jika Anda memaksa input ke fungsi Anda dengan np.asarray() Anda mungkin tidak akan menyadari jika beberapa library yang Anda gunakan menggunakan switch untuk mengembalikan array dengan tipe berbeda.

Ini terdengar seperti bagian numerik / numarray / numpy yang berulang
pengalaman, yang juga tidak terlalu menyenangkan (antarmuka buffer akan
membantu, tetapi saya pikir transisi seperti itu masih akan melibatkan kode manual
perubahan, tidak semuanya sepele). Itu juga tidak mungkin
untuk pustaka seperti Scipy untuk "meningkatkan" ke "larik baru" tanpa
melanggar kompatibilitas ke belakang, jadi masalahnya hanya menggelembung ke atas
ekosistem, memaksa perpustakaan lain untuk membuat keputusan serupa
tinggalkan ruang nama lama.

Jika setiap orang memaksa masukan mereka dengan np.asarray , maka np.matrix tidak akan menjadi masalah :-).

Jika pustaka array yang berbeda dapat menyetujui tipe duck dan kami membatasi pada dtypes yang dapat direpresentasikan oleh protokol buffer, maka itu dapat berfungsi. Tetapi jika inti dari penulisan ulang adalah membuat perubahan antarmuka yang tidak kompatibel pada objek array dan mengimplementasikan dtypes baru, ... Saya benar-benar tidak melihat bagaimana membuatnya bekerja. Contoh konkret: satu hal yang jelas untuk diperbaiki dalam jenis penulisan ulang ini adalah perilaku ndarray.dot pada input berdimensi tinggi. Tetapi jika ada perpustakaan di luar sana yang menghasilkan def f(a, b): a.dot(b) , maka membuat perpustakaan semacam itu berpotensi merusaknya. Tidak masalah apakah library itu disebut numpy atau tidak.

Dan itu bahkan sebelum masuk ke dalam ketidakmungkinan umum untuk menulis ulang semuanya dalam satu ledakan besar, mempertahankan perhatian pengembang saat kami melakukannya, dan tidak hanya memperbaikinya tetapi juga membuatnya jauh lebih baik sehingga dapat meyakinkan orang untuk bermigrasi - semua tanpa ada masukan tambahan dari pengguna. Saya pikir dynd adalah contoh instruktif di sini.

@rgommers Silakan baca lagi apa yang saya tulis: Saya tidak, ulangi tidak , mengusulkan agar NumPy mengadopsi kecepatan LAPACK. Saya mengusulkan bahwa itu memberi sinyal dengan jelas kepada orang-orang yang memiliki harapan seperti itu (yaitu 80% orang di lingkungan saya) bahwa itu tidak.

@ njsmith Aspek utama dari desain ulang seperti yang saya lihat adalah meninggalkan OO. Ini bukan pendekatan yang baik untuk menyusun kode untuk satu struktur data dengan banyak fungsi yang mengerjakannya. Tulis np.dot(a, b) dan masalah yang Anda gambarkan akan segera hilang. Anda dapat memiliki sejumlah implementasi namespace.dot Anda suka. Setiap perpustakaan dapat menggunakan perpustakaan yang disukainya, dan mereka masih dapat beroperasi. Itu OO yang membuat namespace tunggal untuk metode, dan itu masalah.

Ya, itu perbedaan besar dengan kebiasaan Python. Dan ya, akan sulit untuk menerapkan operator selain itu. Tapi saya pikir itu bisa dilakukan, dan saya pikir itu sepadan dengan usahanya.

Hanya untuk menunjukkan bahwa saya mendukung untuk memecahkan sesuatu ;-)

@rgommers Silakan baca lagi apa yang saya tulis: Saya tidak, ulangi tidak, mengusulkan agar NumPy mengadopsi kecepatan LAPACK.

Aku mengerti itu. Kedua paragraf balasan saya tidak berhubungan langsung, maaf kalau membingungkan.

Saya mengusulkan bahwa itu memberi sinyal dengan jelas kepada orang-orang yang memiliki harapan seperti itu (yaitu 80% orang di lingkungan saya) bahwa itu tidak.

Itulah yang saya katakan, konsensus sepertinya proposal Anda akan ditolak. Anda hanya perlu meminta versi yang disematkan ke 80% itu dan menjelaskan mengapa itu yang Anda inginkan.

@ Khinsen OK, maka sangat membingungkan.)

@njsmith Masalah yang sama, di satu sisi. Pengindeksan adalah panggilan metode dengan Python, jadi OO lagi.

Komentar tambahan: Pengindeksan mewah adalah kesalahan desain terbesar di NumPy, menurut pendapat saya, karena NumPy bahkan tidak memiliki (dan tidak pernah) spesifikasi yang tidak ambigu. Itu np.take untuk argumen integer dan np.repeat untuk argumen boolean. Karena boolean adalah subtipe dari bilangan bulat di Python, ini menciptakan ambiguitas untuk argumen yang hanya berisi 0 dan 1.

Sebenarnya ada hubungan dengan topik utas ini, karena inilah jenis kesalahan desain yang terjadi ketika pengembangan berjalan terlalu cepat.

Saya membahas pengindeksan mewah dalam kursus SciPy saya secara eksklusif untuk memberi tahu orang-orang agar tidak menggunakannya. Ada np.take dan np.repeat yang bekerja dengan baik dan tidak menimbulkan masalah. Dan jika Anda menggunakannya sebagai fungsi daripada metode, tidak ada masalah OO juga. Bagi yang tidak suka np.repeat karena namanya tidak menyarankan maksud saat digunakan dengan boolean, kenalkan saja alias: select = np.repeat . Sekali lagi, sesuatu yang tidak perlu dibuat sulit oleh OO.

Perhatikan juga bahwa pengindeksan biasa tidak tunduk pada masalah seperti itu. Itu melakukan apa yang hampir semua orang harapkan untuk dilakukan dalam semua keadaan yang memungkinkan, sehingga dapat diterapkan dalam suatu metode.

Masalah pelik dari sudut pandang saya adalah aritmatika. Anda memang ingin menulis a+b untuk penambahan array, daripada np.add(a, b) , tetapi tidak ada kesepakatan universal tentang apa yang harus dilakukan a+b , khususnya dalam hal hasil dtype . Itu adalah salah satu masalah inti dari Numeric / numarray split, yang mengarah pada pengenalan jenis skalar baru di NumPy, dan itu juga menyebabkan kejutan yang tidak menyenangkan. Saya yakin masalah ini dapat diselesaikan, tetapi tidak dalam komentar sampingan pada diskusi masalah GitHub.

@rgommers Jika "meminta versi yang disematkan ke 80% itu" dimungkinkan, saya akan melakukannya sejak lama. "Itu 80%" bukanlah komunitas terorganisir yang dapat Anda ajak bicara. Banyak sekali orang yang berbagi budaya latar belakang, tetapi tidak berinteraksi satu sama lain. Saran Anda sedikit seperti "meminta pengguna Windows untuk beralih ke Linux" (atau sebaliknya).

Ini adalah poin yang saya coba buat dengan bersikeras pada NumPy sebagai perangkat lunak infrastruktur. Bagi banyak orang, itu hanyalah satu dari ratusan bata lego yang membentuk instalasi perangkat lunak mereka. Mereka tidak secara khusus peduli tentang itu, itu hanya perlu ada dan "bekerja".

Saya tidak ingin menggagalkan ini lebih jauh, tetapi saya tidak tahu apa yang Anda maksud dengan np.repeat dan bool arrays

@ eric-wieser ulangi 0 kali dan Anda menghapusnya dari array, 1 kali dan itu tetap. Saya tidak setuju dengan mengajarkan ini alih-alih mengindeks, tetapi apa pun (keanehan terburuk hilang saat ini, jadi ya di numpy a bool bukanlah int dalam banyak kasus, menerima itu, Anda baik-baik saja sekarang saya pikir, jadi itu bahkan ketidakcocokan dengan daftar jika Anda ingin melihatnya seperti itu, tapi ...).

Poin samping, karena ini tidak ke mana-mana lagi :). Sebenarnya saya agak berharap bahwa memperbaiki barang di numpy secara perlahan akan membuatnya lebih mudah di beberapa titik di masa mendatang membuat numpy lebih tergantikan.

Saran Anda sedikit seperti "meminta pengguna Windows untuk beralih ke Linux" (atau sebaliknya).

Hmm, meminta orang yang secara teknis kompeten (saya harap ...) untuk mempelajari cara kerja nomor versi di dunia nyata sebenarnya tidak seperti tombol Windows ke Linux.

Ini adalah poin yang saya coba buat dengan bersikeras pada NumPy sebagai perangkat lunak infrastruktur.

Dan mungkin, jika kita akan membuat pengalihan ini, Anda akan beralih ke SciPy karena ini adalah infrastruktur selanjutnya? Kapan berhenti menjadi infrastruktur? Dan mengapa NumPy dan infrastruktur lainnya ingin memiliki skema pembuatan versi yang sangat berbeda dari Python itu sendiri dan seluruh ekosistem ilmiah Python?

80% itu "bukanlah komunitas terorganisir yang dapat Anda ajak bicara.

Admin untuk superkomputer yang Anda gunakan benar-benar harus saling berbicara, bukan? Tidak mungkin ada banyak orang berlarian semua memperbarui perangkat lunak pada beberapa sistem itu dan tidak pernah berbicara. Saya tidak bermaksud Anda harus mendidik 80% dari semua sysadmin di seluruh dunia, hanya yang Anda butuhkan.

@eberg Menyatakan bahwa daftar dan larik adalah tipe data berbeda yang hanya berbagi pengindeksan sebagai properti bersama adalah sudut pandang yang valid untuk diterapkan. Ini juga akan membuat keberadaan skalar NumPy tertentu lebih mudah dijelaskan. Tapi saya belum melihat presentasi NumPy yang mengambil sudut pandang ini.

@tokopedia

Admin untuk superkomputer yang Anda gunakan benar-benar harus saling berbicara, bukan?

Tidak. Mereka bahkan tidak tahu tentang keberadaan satu sama lain. Mereka bekerja untuk organisasi yang berbeda di tempat yang berbeda, yang satu-satunya kesamaan adalah memiliki beberapa pengguna yang sama.

Saya tidak bermaksud Anda harus mendidik 80% dari semua sysadmin di seluruh dunia, hanya yang Anda butuhkan.

Ini bukan tentang saya - Saya memiliki solusi yang bekerja dengan baik untuk diri saya sendiri: Saya selalu menginstal Python plus semua pustaka dari sumber, di direktori home saya.

Tentang apa ini adalah tentang orang-orang yang saya ajak berkolaborasi dan orang-orang yang meminta bantuan saya (misalnya karena mereka pernah berpartisipasi dalam salah satu kursus Python saya di masa lalu). Mereka tidak memiliki kompetensi teknis untuk mengelola instalasi Python mereka sendiri dan tunduk pada orang lain (admin atau kolega yang lebih berpengalaman).

untuk mempelajari cara kerja nomor versi di dunia nyata

Dalam budaya latar belakang bersama dari orang-orang yang saya pikirkan, dunia nyata sebenarnya bekerja seperti pembuatan versi semantik, atau pendekatan yang mirip.

Dalam budaya latar belakang bersama dari orang-orang yang saya pikirkan, dunia nyata sebenarnya bekerja seperti pembuatan versi semantik, atau pendekatan yang mirip.

Itu karena mereka menggunakan sejumlah perpustakaan terbatas, kebanyakan bergerak lambat seperti LAPACK & co. Seperti yang ditunjukkan oleh @njsmith , sebagian besar perangkat lunak memiliki nomor versi rendah karena tidak menggunakan pembuatan versi semantik.

@rgommers Mereka menggunakan sebagian besar perpustakaan yang bergerak lambat, meskipun saya tidak akan mengatakan "sejumlah kecil".

Seperti yang ditunjukkan oleh @njsmith , sebagian besar perangkat lunak memiliki nomor versi rendah karena tidak menggunakan pembuatan versi semantik.

Tidak menurut pengalaman saya. Tapi kemudian, "mayoritas" mungkin berarti "sebagian besar yang saya tahu", baik untuk Anda dan saya, dan mungkin ada sedikit tumpang tindih antara paket yang Anda gunakan dan paket yang saya gunakan, di luar ekosistem SciPy.

Dan mungkin, jika kita akan membuat pengalihan ini, Anda akan beralih ke SciPy karena ini adalah infrastruktur selanjutnya? Kapan berhenti menjadi infrastruktur?

Saya memang lebih suka SciPy dan semua dasar-dasar ekosistem SciPy lainnya mengadopsi prinsip yang sama, tetapi secara pribadi saya tidak akan menginvestasikan upaya apa pun untuk memperdebatkan hal ini di mana pun selain untuk NumPy, yang jauh lebih banyak digunakan daripada perpustakaan lain, dan juga jauh lebih mendasar. Array NumPy adalah struktur data pusat untuk banyak perangkat lunak ilmiah, sedangkan SciPy hanyalah kumpulan besar fungsi dari mana aplikasi tertentu menggunakan subset kecil.

Perhatikan juga bahwa SciPy de facto menggunakan versi semantik, meskipun mungkin tidak disengaja, karena hanya mencapai 1.0.

Dan mengapa NumPy dan infrastruktur lainnya ingin memiliki skema pembuatan versi yang sangat berbeda dari Python itu sendiri dan seluruh ekosistem ilmiah Python?

Seluruh ekosistem SciPy memang harus menggunakan pendekatan yang sama, yang (seperti yang saya lihat) yang dominan dalam komputasi ilmiah. Ini tidak berlaku untuk pustaka Python dan Python dari domain lain, yang memiliki kebiasaan berbeda. Pengembangan web, misalnya, jauh lebih konservatif daripada komputasi ilmiah. Ini juga sebagian besar dilakukan oleh orang yang berbeda, yang peduli dengan pengguna yang berbeda. Bahasa Python akan menjadi satu-satunya titik kontak.

Array NumPy adalah struktur data pusat untuk banyak perangkat lunak ilmiah, sedangkan SciPy hanyalah kumpulan besar fungsi dari mana aplikasi tertentu menggunakan subset kecil.

Dan struktur data pusat stabil. Sebagian besar perubahan yang tidak kompatibel dalam rilis tertentu adalah kasus sudut dan sebagian besar tidak dalam perilaku ndarray. Lihat https://github.com/numpy/numpy/blob/master/doc/release/1.13.0-notes.rst#compatibility -notes misalnya. Perhatikan juga bahwa tidak ada dari perubahan itu yang akan memiliki arti untuk sysadmin, jadi meskipun mereka menatap catatan itu untuk waktu yang lama (jika itu akan menjadi 2.0.0) mereka tidak akan dapat memutuskan apakah peningkatan itu baik-baik saja atau tidak.

Perhatikan juga bahwa SciPy de facto menggunakan versi semantik, meskipun mungkin tidak disengaja, karena hanya mencapai 1.0.

SciPy menggunakan skema pembuatan versi dan kebijakan penghentian / penghapusan yang sama persis dengan NumPy. Berada di 0.x untuk waktu yang lama tidak berarti semver.

yang (seperti yang saya lihat) yang dominan dalam komputasi ilmiah

Perbandingan tradisional ekosistem SciPy adalah dengan hal-hal seperti Matlab dan R. Tidak dapat menemukan info apa pun tentang R, tetapi di 3.x dan telah berkembang pesat, jadi mungkin tidak semver. Matlab: pasti tidak semver.

RE: pengindeksan mewah. Memang, ini bisa menggunakan fungsi khusus. Inilah yang dilakukan di TensorFlow, misalnya, dengan tf.gather , tf.gather_nd , tf.scatter_nd , tf.boolean_mask , dll. Hasilnya sedikit lebih bertele-tele daripada membebani [] , tetapi tentunya lebih transparan.

Fitur lain yang dapat membantu adalah anotasi tipe, fitur yang sebagian dimotivasi oleh kesulitan transisi Python 2 ke 3.

Saya tidak mengatakan ini akan mudah. Menurut saya, konsekuensi komunitas adalah masalah yang lebih besar. Ini memang akan membutuhkan banyak energi untuk diterapkan dan kemudian mendorong hilir ke dalam proyek seperti SciPy.

@ Khinsen Saya telah mengikuti diskusi sepanjang minggu dan saya pikir saya memiliki masalah tes praktis untuk menguji pendapat Anda. Ini mungkin item yang bagus untuk melihat bagaimana perspektif Anda akan menangani konflik semacam itu daripada diskusi yang sedikit abstrak sejauh ini.

Saat ini, berkat kerangka Apple Accelerate, versi LAPACK minimum yang dibutuhkan adalah 3.1.ish yang berasal lebih dari satu dekade lalu. Dan saat ini LAPACK ada di 3.8.0. Sementara itu mereka telah membuang cukup banyak rutinitas (usang dan / atau dihapus) dan memperbaiki banyak bug dan yang terpenting memperkenalkan rutinitas baru yang diperlukan untuk mengisi celah antara perangkat lunak komersial dan perangkat lunak ilmiah Python. Hasil akhirnya dirangkum di sini . Saya terus-menerus mengganggu terutama @rgommers dan yang lainnya selama 6 bulan terakhir untuk ini 😃 dan saya dapat meyakinkan Anda jika mereka adalah jenis orang yang, mungkin dengan enggan, digambarkan di sini, ini seharusnya sudah terjadi sekarang dan memecahkan banyak kode orang-orang. Sebaliknya, mereka dengan sabar menjelaskan mengapa tidak mudah untuk menghentikan dukungan untuk Accelerate.

Sekarang ada kebutuhan yang tidak perlu untuk versi yang lebih baru. Itu bukan pembahasan dan kita bisa melewati bagian itu dengan aman. Ada sebagian besar pengguna NumPy dan SciPy yang akan mendapat manfaat dari ini. Tetapi kita tidak bisa begitu saja melepaskannya karena argumen yang telah Anda berikan. Bagaimana Anda mengatasi ini?

Saya tidak menanyakan ini dengan cara yang snarky tetapi karena semua pengembang tampaknya berpikiran sama (dan saya harus mengatakan saya setuju dengan mereka) mungkin penampilan Anda dapat memberikan ide baru. Haruskah kita tetap Mempercepat dan membuat paket NumPy / SciPy baru setiap kali hal seperti itu terjadi? Jika kami melepaskan dukungan untuk berinovasi, apa cara terbaik menurut Anda untuk pergi ke sini?

Saat ini, berkat kerangka kerja Apple Accelerate, versi LAPACK minimum yang dibutuhkan adalah 3.1.ish

@mhvk , ini mungkin menjadi masalah untuk # 9976 di 1,14, yang menurut saya perlu 3.2.2 (edit: mari kita pindahkan diskusi ke sana)

@xoviat : Mari kita bahas tentang masalah itu

@ilayn Terima kasih telah mendorong diskusi ini ke arah konkret dan konstruktif! Sebenarnya ada banyak kesamaan antara situasi itu dan yang memotivasi saya untuk memulai utas ini.

Poin umum utama: ada pengguna / komunitas berbeda yang memiliki kebutuhan berbeda. Beberapa ingin Mempercepat, yang lain menginginkan fitur LAPACK baru. Keduanya memiliki alasan bagus untuk prioritas khusus mereka. Bahkan mungkin ada orang yang menginginkan fitur Accelerate dan LAPACK baru, meskipun hal ini tidak jelas bagi saya.

Di dunia Fortran / C, tidak ada masalah seperti itu karena tumpukan perangkat lunak lebih dangkal. Ada Fortran, LAPACK, dan kode aplikasi, tanpa perantara tambahan. Apa yang terjadi adalah setiap kode aplikasi memilih versi LAPACK tertentu tergantung pada prioritasnya. Pusat komputasi biasanya menyimpan beberapa versi LAPACK secara paralel, masing-masing di direktorinya sendiri, pilihan dibuat dengan memodifikasi kode aplikasi Makefile .

Pelajaran yang dapat dan harus kita ambil ke dalam ekosistem SciPy adalah bahwa memilih versi perangkat lunak bukanlah tugas pengembang perangkat lunak, tetapi orang-orang yang merakit bundel perangkat lunak khusus aplikasi. Di dunia kita, itulah orang-orang yang mengerjakan Anaconda, Debian, dan distribusi perangkat lunak lain, tetapi juga manajer sistem di berbagai tingkatan dan pengguna akhir dengan kompetensi dan motivasi yang tepat.

Jadi proposal saya untuk dilema SciPy / LAPACK adalah untuk menjaga SciPy hari ini menggunakan Accelerate, tetapi memasukkannya ke mode pemeliharaan minimal (mungkin diambil alih oleh orang yang berbeda). Orang yang menginginkan Akselerasi kemudian dapat memilih "SciPy 2017" dan berbahagia. Mereka tidak akan mendapatkan fitur LAPACK baru, tetapi mungkin itu baik-baik saja dengan kebanyakan dari mereka. Pengembangan berlanjut di namespace baru ( scipy2 , scipy2018 atau apa pun), yang beralih ke LAPACK modern. Jika secara teknis memungkinkan, izinkan pemasangan paralel dari dua varian (dan yang akan datang) ini (yang menurut saya seharusnya mungkin untuk SciPy). Jika tidak, orang yang membutuhkan keduanya harus menggunakan beberapa lingkungan (conda, venv, atau lingkungan seluruh sistem melalui Nix atau Guix). Perhatikan bahwa bahkan dalam skenario kedua ini, saya sangat menyarankan untuk mengubah namespace dengan setiap perubahan yang tidak kompatibel, untuk memastikan bahwa pembaca kode Python di tingkat mana pun memahami untuk versi SciPy mana kode itu ditulis.

Ide keseluruhannya adalah bahwa pengembang mengusulkan hal-hal baru (dan berkonsentrasi pada pengembangannya), tetapi tidak mengiklankannya sebagai "lebih baik" dalam arti umum, atau sebagai pengganti universal. Memilih kombinasi versi perangkat lunak yang tepat untuk tugas tertentu bukanlah pekerjaan mereka, ini pekerjaan orang lain.

Gagasan umum bahwa pengembangan dan perakitan dilakukan secara mandiri dan oleh orang yang berbeda juga menunjukkan bahwa paket besar saat ini harus dipecah menjadi unit-unit yang lebih kecil yang dapat berkembang dengan kecepatan yang berbeda. Tidak ada alasan hari ini untuk NumPy yang berisi antarmuka LAPACK kecil dan alat seperti f2py . Untuk SciPy, mungkin masuk akal untuk memiliki namespace umum yang menunjukkan koherensi dan kebijakan pengembangan yang sama, tetapi sub-paket dapat didistribusikan secara independen. Pendekatan mega-paket kembali ke motto "termasuk baterai" Python yang hebat 20 tahun lalu. Basis pengguna saat ini terlalu beragam untuk itu, dan pengemasan perangkat lunak secara umum telah dikenali sebagai aktivitas yang berbeda. Termasuk baterai sekarang harus menjadi tugas Anaconda.

Hambatan utama untuk mengadopsi pendekatan semacam itu adalah distribusi Linux tradisional seperti Debian atau Fedora dengan pendekatan "satu instalasi Python per mesin". Saya pikir mereka dapat beralih ke beberapa lingkungan virtual seluruh sistem dengan upaya yang wajar, tetapi saya belum terlalu memikirkan hal ini. Bagi saya, masa depan pengemasan perangkat lunak adalah sistem berbasis lingkungan seperti conda atau Guix.

Saya tidak melihat bagaimana semua preposisi yang Anda kemukakan sejauh ini, kompatibel dengan langkah-langkah ini

• Anda baru saja menciptakan kembali kegilaan dari gambar berikut
  
  Baru saja dihitung dan saya memiliki 27 salinan sekarang di mesin Windows saya. Sekarang kalikan dengan 10 sejak (rilis lebih sering terjadi di sini) dan dengan 2 (karena siklus rilis NumPy dan SciPy tidak bergantung). Pada tahun 2025 saya akan dengan mudah memiliki 15 salinan dari setiap perpustakaan dan 10 LAPACK dan 5 f2pys sebagai dependensi. Jangankan pemeliharaan membebani hanya beberapa lusin orang di kedua paket, ini tidak akan berfungsi. (C ++ tidak relevan, masukkan lib standar apa pun). Tanyakan kepada pengembang kode komersial mana pun tentang Win dan beri tahu mereka bahwa ini adalah ide yang bagus. Saya tidak bertanggung jawab atas apa yang terjadi selanjutnya dalam pertukaran itu.
• Kemudian Anda meningkatkan granularitas paket dan sekarang semua melakukan semuanya sendiri dengan versi paket yang berbeda; f2py merusak sesuatu dalam satu versi sehingga SciPy berhenti membangun di versi berikutnya tetapi masih bergantung pada versi NumPy sebelumnya. Jadi beberapa entitas holistik harus menyatukan mereka secara gratis.
• Kemudian Anda juga menjadikan Anaconda (atau entitas lain) sebagai perusahaan yang sangat bergantung seperti Accelerate dulu. Atau hanya akan ada kelimpahan "orang lain".
• Kemudian Anda memobilisasi sebagian besar basis pengguna ke dalam alur kerja yang sebenarnya tidak mereka inginkan (termasuk saya) yang melibatkan lingkungan virtual.
• Kemudian Anda bahkan memodifikasi sistem operasi Linux secara sepintas (yaitu ... maksud saya hanya membaca beberapa milis mereka, menyenangkan).

Mungkin Anda sedikit menyimpang.

(Ini telah menjadi diskusi gratis-untuk-semua, jadi saya akan melanjutkan dan melompat).

Masalah dengan mempertahankan dukungan untuk akselerasi bukanlah karena ia tidak memiliki API LAPACK yang lebih baru. Jika itu masalahnya, kami dapat mengirimkan shim LAPACK yang lebih baru dan selesai. Masalahnya adalah ada fungsi dasar yang mengembalikan hasil yang salah dalam skenario tertentu. Tidak ada cara untuk menyiasatinya selain menulis fungsi BLAS kita sendiri. Dan jika kita melakukan itu, kita mungkin juga membutuhkan OpenBLAS atau MKL.

@xoviat Ini semua telah dibahas di https://github.com/scipy/scipy/pull/6051. Seperti biasa, tidak pernah sesederhana itu. Tapi intinya bukanlah membahas Accelerate drop tetapi menggunakannya sebagai kasus penggunaan untuk siklus dev yang sebenarnya untuk versi baru.

@ilayn Ya, saya yakin sudah tahu tentang poin-poin yang saya buat. Tapi komentar itu untuk @khinsen; Saya pikir dia mendapat kesan bahwa kami benar-benar dapat mempertahankan dukungan Accelerate.

Orang dapat berargumen bahwa fitur (atau batasan) ekosistem Python adalah Anda mendapatkan satu versi perpustakaan tanpa peretasan nama yang mengerikan. Ini terjadi pada inti Python. Inilah sebabnya mengapa ada pustaka bernama _lib_ dan _lib_ 2 yang memiliki tujuan yang sama tetapi perbedaan API. Bahkan bijih Python bekerja dengan cara ini. Tidak mungkin untuk mencampur pustaka standar di seluruh versi meskipun keduanya secara teknis dapat digunakan pada Python modern tanpa seseorang merobeknya dan meletakkannya di PyPi. Ada banyak pertanyaan StackOverflow tentang ini, semuanya dengan kesimpulan yang sama.

@ilayn Jika karena alasan tertentu Anda ingin memiliki semua kemungkinan kombinasi dari semua versi dari semua yang ada di mesin Anda, ya, itu berantakan. Tetapi mengapa Anda menginginkan itu? Jika Anda membatasi diri Anda pada kombinasi yang sebenarnya Anda butuhkan untuk skenario aplikasi Anda, saya yakin itu akan lebih sedikit. Sebagai contoh, saya menyimpan tepat dua lingkungan Python di mesin saya: satu dengan Python 2 + NumPy 1.8.2 untuk menjalankan kode saya yang berusia 20 tahun, dan satu lagi mewakili keadaan seni sekitar dua tahun lalu untuk yang lainnya ( dua tahun lalu karena saya memasangnya dua tahun lalu, dan tidak pernah melihat alasan untuk meningkatkan versi setelah itu).

Mengenai perincian, saya mungkin tidak terlalu jelas dalam proposisi saya. Yang saya anjurkan adalah lebih detail dalam pengemasan, bukan dalam pengembangan. Saya berharap pengembangan, katakanlah, f2py dan SciPy akan terus berlanjut dalam koordinasi yang erat. f2py-2018 dan SciPy-2018 harus bekerja sama. Itu tidak berarti mereka harus dikemas sebagai satu kesatuan. Tujuannya adalah untuk memberikan lebih banyak kebebasan bagi manajer distribusi perangkat lunak untuk melakukan pekerjaan mereka.

Saya pasti tidak ingin membuat Anaconda atau distribusi lainnya menjadi ketergantungan. Ini lebih seperti "kelimpahan milik orang lain", meskipun saya tidak berharap jumlah distribusi tumbuh menjadi "kelimpahan", mengingat bahwa merakitnya membutuhkan banyak pekerjaan.

Saya tidak tahu alur kerja apa yang diinginkan "basis pengguna". Saya melihat banyak basis pengguna berbeda dengan persyaratan berbeda. Secara pribadi saya akan memilih beberapa lingkungan, tetapi jika ada basis pengguna yang signifikan yang menginginkan satu lingkungan per mesin, beberapa distribusi akan mengurusnya. Tetapi lingkungan virtual diciptakan karena suatu alasan, mereka memecahkan masalah nyata. Distribusi level sistem seperti Nix atau Guix membawa mereka ke level lain. Saya tidak berharap mereka pergi.

BTW, saya sebenarnya mengikuti milis salah satu distribusi Linux (Guix). Tidak terlalu menyenangkan, tapi banyak pekerjaan kasar yang membumi. Saya senang ada orang yang melakukan ini.

@xoviat Saya tidak menyarankan untuk "pertahankan dukungan Accelerate". Saya hanya menyarankan untuk menyimpan varian SciPy (cukup banyak yang saat ini) di sekitar bukan sebagai rilis yang ketinggalan jaman untuk museum, tetapi sebagai varian yang menarik untuk kelompok pengguna tertentu: mereka yang menggunakan Accelerate lebih penting daripada menyelesaikan masalah itu Percepat kreasi untuk orang lain. Orang-orang yang "Mempercepat dulu" harus hidup dengan konsekuensi pilihan mereka. Beberapa masalah tidak akan pernah bisa diperbaiki untuk mereka. Itu mungkin baik-baik saja dengan mereka ("bug yang dikenal lebih baik daripada bug yang tidak dikenal"), jadi mengapa memaksa mereka menjadi sesuatu yang berbeda?

Ini benar-benar tentang pelabelan dan komunikasi. Saya ingin menjauh dari citra ideal perangkat lunak yang mengikuti jalur kemajuan linier, dengan versi yang lebih baru menjadi "lebih baik" seperti yang ditunjukkan oleh nomor versi "lebih tinggi". Saya ingin mengganti gambar ini dengan gambar yang saya anggap lebih realistis: tidak ada hubungan urutan yang jelas antara rilis perangkat lunak. Yang dihasilkan oleh komunitas pengembang yang koheren berumur panjang memiliki urutan temporal, tetapi itu tidak menyiratkan apa pun tentang kualitas atau kesesuaian untuk aplikasi tertentu.

Jika gambar yang diidealkan benar, kami tidak akan melihat percabangan, dan kami tidak akan memiliki lingkungan virtual. Juga tidak proyek seperti VersionClimber .

Apa yang saya usulkan adalah bahwa pengembang perangkat lunak harus menerima kenyataan ini daripada menyangkalnya. Mereka harus mengembangkan (dan, yang terpenting, mengemas dan memberi label) produk mereka untuk dunia yang beragam.

@khinsen Jika Anda Dan bahkan jika tidak, apa yang terjadi ketika seseorang di jalan menyalahkan SciPy atas masalah akselerasi? Apa yang terjadi jika seseorang ingin memiliki kuenya dan memakannya juga? Saya hanya bisa melihat itu terjadi.

@xoviat Tidak, saya tidak setuju dengan hasil yang salah dari fungsi aljabar linier. Tapi saya yakin ada banyak pengguna SciPy yang tidak membutuhkan fungsi yang terpengaruh sama sekali. Di utas yang Anda rujuk, seseorang menyarankan untuk menghapus / menonaktifkan fungsi yang terpengaruh ketika Akselerasi terdeteksi, yang menurut saya merupakan solusi yang baik (catatan: Saya tidak dapat menilai upaya yang diperlukan untuk menerapkan ini).

Di satu sisi, ini adalah bagian dari masalah mega-paket. Dengan distribusi yang lebih terperinci, akan lebih mudah untuk memilih barang-barang yang berfungsi, baik pada tingkat perakitan pengembangan maupun distribusi. Seseorang bahkan dapat membayangkan assembler distribusi menyusun distribusi SciPy khusus domain dan platform di mana sub-paket yang berbeda menggunakan versi LAPACK yang berbeda, misalnya untuk digunakan dalam konteks HPC.

Tapi saya yakin ada banyak pengguna SciPy yang tidak membutuhkan fungsi yang terpengaruh sama sekali.

Ada sedikit bukti untuk pernyataan ini dan saya justru bertaruh sebaliknya. Fungsi ini banyak digunakan tetapi hanya gagal dalam skenario tertentu; dengan kata lain hasil Anda mungkin benar tetapi mungkin juga tidak. Ya, ini mungkin berlaku untuk SciPy yang saat ini Anda instal jika menggunakan OSX. Ya, ini perlu diperbaiki.

Sejauh mempertahankan cabang terpisah, saya tidak berpikir ada orang yang akan menentang memberi Anda akses tulis ke cabang tertentu untuk Anda pelihara. Tapi ini adalah perangkat lunak open source dan orang mengerjakan apa yang mereka inginkan; Saya skeptis bahwa banyak orang akan tertarik untuk mempertahankan cabang itu.

Sebenarnya, menurut saya anaconda SciPy dikompilasi dengan MKL, jadi Anda tidak akan terpengaruh dalam kasus itu. Tapi mengapa Anda peduli tentang dukungan akselerasi?

@xoviat Sepertinya ada kesalahpahaman besar di sini. Saya sama sekali tidak memiliki kepentingan pribadi dalam masalah khusus ini. Saya tidak menggunakan rutinitas aljabar linier dari SciPy.

Anda menunjuk ke utas tentang masalah SciPy dan bertanya bagaimana saya akan menangani situasi seperti itu. Utas dengan jelas menunjukkan keengganan untuk begitu saja melepaskan dukungan Accelerate, dari mana saya menyimpulkan bahwa ada grup pengguna yang signifikan yang akan terpengaruh oleh perubahan semacam itu. Jika grup pengguna itu tidak ada, lalu di mana masalahnya? Mengapa SciPy belum menjatuhkan dukungan Accelerate?

@xoviat Mempertahankan cabang terpisah itu mudah bagi siapa saja. Tidak perlu untuk dihosting di repositori GitHub yang sama. Dengan kata lain, cabang bukanlah masalahnya. Masalahnya adalah namespacing, untuk membuat keberadaan paralel dari versi SciPy terpisah menjadi transparan bagi pengguna (dan assembler distribusi).

Hari ini, ketika Anda melihat kode yang mengatakan "import scipy", Anda tidak tahu kisaran versi SciPy mana yang seharusnya berfungsi (yaitu telah diuji sampai taraf tertentu). Dalam kasus terbaik, ada README yang mengatakan "SciPy> = 0.8" atau semacamnya. Kebiasaan ini didasarkan pada asumsi bahwa versi yang "lebih tinggi" selalu "lebih baik" dan tidak pernah menurunkan (merusak, memperlambat, ...) apa pun. Dan anggapan itu salah.

Sebaliknya, jika kode mengatakan "import scipy2017 as scipy", maka jelas bagi setiap pembaca bahwa menggunakannya dengan versi sebelumnya atau yang lebih baru dapat menimbulkan kejutan yang buruk. Dan jika versi SciPy lama menghilang (secara efektif, karena kurangnya perawatan), maka kode seperti itu akan gagal dengan pesan kesalahan, daripada terus bekerja dengan tidak dapat diandalkan.

Ini adalah satu hal yang saya coba buat di utas ini. Koeksistensi versi yang berbeda adalah kenyataan. Gagasan bahwa lebih tinggi lebih baik adalah mimpi. Mari bersikap realistis dan mengatur diri kita sendiri untuk dunia nyata, dengan mengakui alam semesta multi-versi dan menyesuaikan komunikasi setiap orang untuk mencegah kesalahpahaman.

Nah, tak tahu… menurut saya jika menyangkut peringatan, impor versi tertentu bukanlah peringatan, itu dilarang menggunakan versi yang berbeda, karena pengguna yang memiliki masalah seperti yang Anda gambarkan tidak akan berani mengubah kode Anda. Peringatan akan muncul jika Anda mencetak peringatan pada install / runtime yang belum diuji untuk semua kecuali versi numpy tertentu?

Saya kira membuat jenis paket tambahan itu mungkin. Saya juga berharap itu hanya akan menciptakan jenis neraka yang berbeda. Banyak yang mungkin bertahan, tetapi pemeriksaan jenis misalnya tidak akan dan tidak bisa ketika Anda mencampur dua versi, jadi pada dasarnya Anda tidak akan tahu apakah itu bisa atau tidak bisa bekerja sampai Anda mencobanya (dan tidak ada yang akan mengujinya!).
Dan kecuali Anda menyarankan mengizinkan untuk mencampur dua versi, saya pikir solusi scipy2017 Anda hanya akan memperburuk keadaan. Sepertinya kita lebih membutuhkan sesuatu seperti pemilihan env virtual dinamis / runtime (seperti pin_import_version("1.6<numpy<1.10", level="raise") sebelum impor apapun pada level python).

Impor spesifik masuk akal jika Anda memiliki perubahan besar yang menghalangi (sedikit seperti py2 / py3), dan kami telah melihat bahwa kami memiliki pendapat berbeda tentang di mana atau pada skala waktu apa garis "utama" itu terlihat.

Kompatibilitas mundur NEP # 11596 telah dikirimkan, dapatkah kita menutupnya?

Kompatibilitas mundur NEP # 11596 telah dikirimkan, dapatkah kita menutupnya?

Ya, kita bisa menutup ini. Terlepas dari NEP tersebut (yang secara eksplisit menyebutkan semver sebagai alternatif yang ditolak), konsensus pengembang inti di sini adalah bahwa kami tidak ingin beralih ke semver. Oleh karena itu menutup sebagai wontfix.

Terima kasih untuk diskusi semuanya.