Ipython: Kembalikan kemampuan readline?

Saya bersedia melakukan pekerjaan untuk mengembalikan ini tepat waktu untuk 6.0, jadi saya akan menandai #10329 di sini.

Saya pikir ini adalah masalah yang sangat penting karena pengguna lama dan pendukung IPython merasa frustrasi oleh atau bahkan tidak mau menggunakan IPython 5 seperti sekarang.

Saya senang menambahkannya kembali sebagai opsi, meskipun sebagian besar kode telah dihapus dan kemungkinan besar akan banyak upaya untuk mengintegrasikan kembali readline.

Jika kita dapat menemukan cara untuk menjadikannya opsional (sehingga dapat berkembang lebih cepat daripada inti untuk memperbaiki kembali bug potensial yang diperkenalkan oleh kebangkitan, itu akan sangat bagus.

Kami mungkin ingin menunda #10356 jika kami mengembalikan RL.

Lihat #9260 juga.

Dan #9399 adalah sebagian besar penghapusan.

Saya sangat -1 dalam hal ini. Kami dapat menghapus banyak kode dan kerumitan saat kami membuang readline, (dan kami sedang berupaya untuk menjatuhkan lebih banyak lagi), sambil secara dramatis meningkatkan pengalaman pengguna bagi sebagian besar pengguna. Jika kami mengembalikan opsi readline, kami memiliki semua kerumitan dari kedua antarmuka untuk dipertahankan ~ selamanya. Kami selalu tahu perubahan sebesar ini akan merusak beberapa alur kerja, tetapi saya yakin ini adalah peningkatan bersih, dan saya tidak ingin kami terlibat dalam bisnis pemeliharaan dua antarmuka terminal alternatif.

Saya lebih suka kita:

1. Terus bekerja pada apa pun yang dapat kami tingkatkan baik di IPython maupun di prompt_toolkit untuk menghilangkan hambatan untuk beralih. Jonathan secara umum sangat responsif dan membantu setiap kali kami melakukan ping kepadanya tentang masalah yang berkaitan dengan PTK, jadi saya pikir kami memiliki peluang bagus untuk mendapatkan perubahan apa pun yang perlu kami terima. Ini termasuk hal-hal seperti mendokumentasikan lebih baik cara mengatur pintasan khusus, dan mungkin bereksperimen dengan membaca .inputrc (walaupun saya lebih suka itu adalah opsi off-by-default, karena alasan yang telah saya jelaskan di tempat lain). Jika kami memberi orang pilihan mudah untuk kembali ke readline, peningkatan ini tidak akan terjadi.
2. Jika masih ada orang yang benar-benar bersikeras menggunakan readline, buat paket terpisah seperti rlipython yang menyediakan antarmuka terminal, tetapi jelaskan bahwa itu dikelola komunitas, bukan sesuatu yang kami dukung secara resmi.

Mengingat bahwa selalu ada sejumlah masalah dengan pyreadline di Windows (paling tidak itu, fakta bahwa itu secara global memengaruhi REPL Python standar serta IPython) saya lebih suka tidak memerlukan (py) readline tetap default, di setidaknya di Windows. Jika pengguna lebih suka menginstal pyreadline secara manual dan mengaktifkannya, tidak apa-apa, tetapi IPython harus berfungsi tanpa kehadiran pyreadline, dan tidak memasukkannya sebagai ketergantungan instalasi normal.

Jika masih ada orang yang benar-benar bersikeras menggunakan readline, buat paket terpisah seperti rlipython yang menyediakan antarmuka terminal, tetapi jelaskan bahwa itu dikelola komunitas, bukan sesuatu yang kami dukung secara resmi.

Saya pikir itu masuk akal, meskipun saya percaya memiliki beberapa integrasi (seperti flag dan/atau variabel env) dengan IPython yang mengembalikan perilaku sebelumnya masuk akal. Tujuannya adalah agar skrip dan resep yang sudah tersebar dengan baik yang mengandalkan readline IPython masih berfungsi dengan sakelar sederhana.

Dugaan saya adalah bahwa konfigurasi sederhana di IPythonApp, yang membuat kelas TerminalInteractiveShell menggunakan sifat, ditambah flag --readline yang memiliki nilai preset ke paket eksternal yang dikenal sudah cukup.

Ipython sebagai paket terpisah juga memungkinkan untuk tidak memblokir IPython 6, dan mendapatkan siklus iterasi yang cepat jika perlu.

Jika kami memberi orang pilihan mudah untuk kembali ke readline, peningkatan ini tidak akan terjadi.

Saya ragu itu sepenuhnya benar. Multiline, highlighting, dan sekarang penyelesaian masih merupakan keuntungan besar dari antarmuka PTK. Dan pengguna yang menyematkan ke 4.x karena mereka bahkan tidak dapat menggunakan kedua RL/PTK secara paralel tidak memiliki insentif untuk mengirim patch ke IPython/PTK untuk memperlancar perilaku.

Saya tidak akan mengintegrasikannya dengan sakelar, karena itu membuatnya tampak seperti opsi yang didukung, dan orang-orang akan mengajukan bug tentangnya di sini. rlipython lebih sedikit mengetik daripada ipython --readline , dan jika orang ingin menggunakannya sebagai ipython , mereka dapat membuat alias.

Sekedar catatan tentang pengalaman ctrl-r :

Di Bash, ketika Anda menekan ctrl-r lalu tekan escape, itu akan membuat Anda keluar.

Dalam yang satu ini tidak melakukan apa-apa ketika harus menutup area pencarian.

Sekedar catatan tentang pengalaman ctrl-r saat ini:
Di Bash, ketika Anda menekan ctrl-r lalu tekan escape, itu akan membuat Anda keluar.
Dalam yang satu ini tidak melakukan apa-apa ketika harus menutup area pencarian.

Yang ini mudah diperbaiki, tetapi tidak sepenuhnya:

 ~/dev/ipython master [1]"!!" $ git diff
diff --git a/IPython/terminal/shortcuts.py b/IPython/terminal/shortcuts.py
index 22ad111..89713cd 100644
--- a/IPython/terminal/shortcuts.py
+++ b/IPython/terminal/shortcuts.py
@@ -54,6 +54,10 @@ def register_ipython_shortcuts(registry, shell):
     registry.add_binding(Keys.ControlC, filter=HasFocus(DEFAULT_BUFFER)
                         )(reset_buffer)

+
+    registry.add_binding(Keys.Escape, filter=HasFocus(SEARCH_BUFFER)
+                        )(reset_search_buffer)
+
     registry.add_binding(Keys.ControlC, filter=HasFocus(SEARCH_BUFFER)
                         )(reset_search_buffer)

Itu akan berhasil, tetapi I-search-backward: akan tetap terlihat sampai Anda menekan tombol baru. Kunci baru ini akan berperilaku jika pencarian mundur dihentikan, tetapi rasanya sangat aneh.

Terima kasih telah membuka ini, @ivanov! Saya akan membahas detailnya sedikit lebih hati-hati, saya juga akan mendorong lebih banyak umpan balik pada daftar ini. Ini jelas merupakan keseimbangan yang rumit dan kontroversial, jadi pertanda baik bahwa lebih banyak suara setidaknya dapat menginformasikan proses keputusan kami.

Hanya pembaruan tentang kemungkinan cara maju untuk upaya ini: alih-alih membawa kode yang dihapus ke IPython yang tepat, @Carreau membuat proyek baru hanya dengan kode berbasis readline lama di Carreau/rlipython , dan membuat #10373 yang memungkinkan pengguna untuk menyesuaikan bagian ini.

FYI: masalah yang dijelaskan di milis:

Saya bertanya terutama karena di SMC setidaknya, jika Anda mencoba menempelkan banyak
garis yang ditempelkannya di baris pertama dan diam-diam mengabaikan semuanyalain . Ini mungkin masalah dengan tingkat dukungan xterm di SMC
(yaitu, istilah.js). Namun, itu cukup membuat frustrasi.

Ini menunjukkan bahwa terminal ini tidak mendukung pasta tanda kurung.
IMHO: Saya pikir hari ini kita dapat mengharapkan dari terminal mana pun untuk mendukungnya: https://cirw.in/blog/bracketed-paste (Setidaknya prompt_toolkit akan memerlukan tempel tanda kurung, untuk menempelkan teks multiline.)

Mungkin ada baiknya menambahkan dukungan readline lagi, tetapi perhatikan bahwa beberapa bug yang disebutkan sudah diperbaiki atau akan menerima perbaikan. Masalah terbesar mungkin adalah terminal Emacs (yang sebenarnya bukan terminal yang kompatibel dengan xterm dan tidak akan pernah didukung), dan dukungan .inputrc yang pada akhirnya akan datang, tetapi karena masalah bandwidth/prioritas di pihak saya, akan memakan waktu.

Bagaimanapun, terus laporkan masalah pengalaman pengguna. Ini penting.

@pfmoore itu poin yang bagus. Saya ragu lingkungan Windows mana pun yang terluka karena kurangnya pyreadline. Jika kita mengembalikan UI readline, mungkin masuk akal untuk melakukan ini hanya untuk readline 'benar', baik itu di IPython atau paket rlipython .

Salah satu keuntungan dari paket rlipython terpisah adalah dapat digunakan dengan rilis IPython 5 yang ada, sedangkan melakukannya di IPython sendiri jelas hanya akan berfungsi untuk rilis IPython baru.

Saya ingin menambahkan #9799 sebagai sumber ketidaknyamanan lainnya dengan default prompt_toolkit. Saya akan sangat senang dengan paket eksternal tambahan untuk diinstal.

pyreadline menyebalkan di Windows, tetapi prompt-toolkit juga memiliki masalah. Jadi di antara 2 solusi yang tidak memuaskan, solusi "utang teknis" yang lebih sedikit terlihat seperti solusi terbaik: prompt-toolkit.

Saya pikir intinya adalah bahwa Prompt_toolkit lebih baik untuk sebagian orang, dan readline lebih baik untuk orang lain. Jadi pertanyaannya adalah, apakah perlu untuk memotong orang-orang readline untuk menghindari mempertahankan kode tambahan?

pyreadline menyebalkan di Windows, tetapi prompt-toolkit juga memiliki masalah. Jadi di antara 2 solusi yang tidak memuaskan, solusi "utang teknis" yang lebih sedikit terlihat seperti solusi terbaik: prompt-toolkit.

Saya pikir intinya adalah bahwa Prompt_toolkit lebih baik untuk sebagian orang, dan readline lebih baik untuk orang lain. Jadi pertanyaannya adalah, apakah perlu untuk memotong orang-orang readline untuk menghindari mempertahankan kode tambahan?

Perhatikan bahwa saat ini PR terlampir (#10373) adalah 4 baris, dan hanya merupakan opsi konfigurasi untuk menjadikannya opsi konfigurasi. Kode readline bahkan tidak akan berada di IPython dan akan menjadi ekstensi.

Pertanyaan sebenarnya adalah:

• A: Apakah boleh jika readline-ipython adalah executable terpisah dengan ejaan yang berbeda.
• B: Atau untuk skrip dan ekstensi yang keluar ke IPython, (misalnya emacs), apakah itu opsi konfigurasi IPython.

Dalam kedua kasus readline tidak akan membuat ketergantungan IPython lagi.

Itu memang memengaruhi beberapa fungsi yang lebih sederhana untuk disimpan di IPython, tetapi pertentangan utama saat ini adalah A atau B.

Dari sisi emacs baik-baik saja. B tampaknya lebih fleksibel dalam jangka panjang.

Saya kira, bagi kita yang lebih suka readline, kita juga ingin readline untuk IPython keluar - jadi B.

Saya sudah memikirkan hal ini untuk sementara waktu dan berbicara dengan beberapa orang di tim yang saya punya kesempatan untuk terlibat secara langsung. Inilah pendapat saya tentang masalah ini. Saya belum menelepon keputusan akhir, tapi saya mencoba untuk memindahkan kita lebih dekat dengan resolusi. BTW, saya ingin menekankan bahwa saya sangat berterima kasih kepada tim Prompt Toolkit, karena sebagian besar telah memberi kami pengalaman pengguna yang luar biasa, modern, dan berkualitas tinggi. Tentang masalah yang dihadapi:

• kekhawatiran pengguna yang membutuhkan readline sangat nyata, dan saya pikir kita harus menemukan solusi yang baik untuk mereka sekarang, bahkan jika biayanya membawa beberapa kode tambahan di/sekitar IPython.

• Kami akan terus bekerja dengan tim PT untuk meningkatkannya menuju paritas fitur dengan readline di mana itu menjadi masalah (saya sadar ini memiliki banyak koleksi fitur yang tidak dimiliki RL).

• Bahkan jika PT meningkat lebih jauh, saya masih dapat melihat situasi di mana readline lama biasa akan berharga. PT, berdasarkan kecanggihannya, cenderung lebih lambat atau lebih rapuh ketika mengatakan berjalan di dalam tmux di atas ssh dalam shell ipython di dalam Emacs. Itu adalah kasus penggunaan yang valid yang harus kami dukung dengan baik, dan yang dulu kami lakukan.

Mengingat hal ini, saya pikir solusi kompromi yang baik sejalan dengan apa yang telah diusulkan @Carreau dalam PR-nya:

• kami mendukung readline tetapi hanya melalui paket pihak ketiga yang harus diinstal secara manual oleh pengguna.

• pengguna kemudian dapat mengatur penggunaan paket ini di file konfigurasi mereka, menyebutnya di baris perintah, atau menulis alias shell atau skrip pembungkus kecil. Ya, ini memerlukan sedikit kerja ekstra dari pihak pengguna kasus sudut ini, tetapi ini memberi mereka solusi bersih dengan biaya minimal, sementara sebagian besar pengguna yang dapat menggunakan PT (dan manfaat dari fitur-fiturnya) terus melakukannya tanpa gangguan .

Ini berarti mendukung untuk sementara paket tambahan ini, tetapi saya tidak membayangkan itu akan banyak bekerja: kode itu hampir tidak berubah dalam beberapa saat, dan kita tidak berbicara tentang menambahkan banyak fitur baru. Cukup mempertahankan kompatibilitas dengan perilaku dasar historis yang ada.

Satu-satunya biaya yang saya lihat agak signifikan adalah (disebutkan oleh @Carreau) mungkin ada kode yang ingin kami robek sehingga ini akan mencegah kami menghapusnya. Saya melihat bahwa sebagai harga yang harus kita bayar untuk kepentingan pengguna kita, setidaknya untuk saat ini. Jika suatu saat nanti kita benar-benar menemukan diri kita dalam situasi di mana PT adalah pengganti 100% untuk RL dalam setiap kasus yang mungkin, kita dapat meninjau kembali. Tetapi untuk saat ini, menyimpan kode tujuan khusus yang sedikit basi untuk kepentingan beberapa bagian dari pengguna kami adalah hal yang benar untuk dilakukan. Selama bertahun-tahun kami telah memiliki beberapa jenis kode kasus khusus (windows, py2/3, dll.) dan saya yakin kami akan melakukannya lagi di masa mendatang. Melayani alur kerja pengguna kami, menurut saya, harus diprioritaskan daripada pembersihan kode (dalam situasi ini, tidak membuat pernyataan menyeluruh).

Bagaimana ini terdengar?

BTW, saya pikir 'perbaikan' ini harus di-backport ke seri 5.x: jika ada, saya menduga populasi pengguna yang masih menggunakan python 2.x memiliki tumpang tindih yang baik dengan orang yang bekerja dari jarak jauh di server yang lebih lama. Jadi pilihan saya adalah membuat paket eksternal menjadi kompatibel dengan python 2-3, dan untuk mem-backport sisi ipython dari kode ke 5.x.

Terima kasih Fernando telah meluangkan waktu untuk menanggapi, dan terutama untuk menjangkau beberapa orang.
Saya akan memoles PR saya, menggabungkannya dan mem-backportnya ke 5.0.

Saya telah rlipython di GitHub untuk siapa saja yang tertarik untuk memelihara antarmuka readline. Saya tidak akan mempertahankan, dan tidak akan mempublikasikannya di PyPI, tetapi Anda dipersilakan untuk melakukannya, dan mungkin merupakan hal yang baik untuk memindahkan ini ke https://github.com/ipython-contrib jika Anda memerlukan org .

Terima kasih !

Saya sebenarnya berpikir kita harus meng-host ini di org IPython utama, dan meletakkannya di pypi. Kami juga dapat mengirimkan pesan yang sedikit lebih ramah kepada komunitas, seperti:

ini adalah sesuatu yang kami tawarkan untuk mendukung kompatibilitas historis dan kasus penggunaan spesifik tertentu di mana antarmuka utama kami (prompt-toolkit) tidak optimal. Tapi kami tidak membayangkan perkembangan yang signifikan selain memperbaiki bug kritis. Kami hanya memiliki sumber daya untuk menawarkan ini sebagai solusi upaya terbaik. Jika Anda tertarik untuk melakukan pengembangan signifikan pada alat ini, beri tahu kami melalui masalah, dan kami dapat menjelajahi mentransfer pemeliharaan paket kepada Anda."

Jika @ivanov memiliki beberapa siklus untuk

Terima kasih @Carreau telah mendorong pekerjaan sejauh ini!

Terima kasih semuanya, terutama @Carreau karena telah meningkatkan rlipython . Saya sudah mulai mengerjakannya dan mencambuknya. Jika ada yang melewatkannya, sekarang tinggal di bawah ipython/rlipython . Saya akan mencoba untuk merilisnya dalam dua minggu ke depan saat saya mulai bekerja dengannya, tetapi untuk saat ini saya dapat mengatakan itu berhasil! Ada satu masalah yang diketahui saat ini - Perintah Masuk/Keluar tidak diwarnai, yang saya lacak di ipython/rlipython#3, tetapi selain itu, tampaknya bagus.

@ivanov , ping saya jika Anda ingin membantu ... Saya telah menawarkan di atas tetapi saya lebih dari sedikit naif tentang ketersediaan waktu saya beberapa minggu terakhir ini. Meskipun demikian saya ingin membantu ini mencapai solusi yang solid untuk semua pengguna baris cmd, jadi saya masih bersedia untuk bergabung jika Anda membutuhkan bantuan (dan akan senang melakukannya :)

Ditutup oleh #10373 dan di-backport sebagai #10463

Hai, dengan masalah ini ditutup, apakah ada cara untuk menonaktifkan prompt_toolkit sepenuhnya?

Hai, dengan masalah ini ditutup, apakah ada cara untuk menonaktifkan prompt_toolkit sepenuhnya?

ya, jika Anda menyetel TerminalIPythonApp.interactive_shell_class ke rlipython di file konfigurasi Anda, maka Prompt_toolkit seharusnya tidak diimpor. Readme rlipython memberikan info lebih lanjut tentang cara melakukan ini.

Untuk siapa pun yang masih berlangganan masalah ini: Saya baru saja merilis rlipython versi 0.1.0, sekarang Anda dapat pip install rlipython dan membuat readline lama bekerja secara default di IPython setelah Anda import rlipython; rlipython.install() .

Terlambat ke pesta, tetapi izinkan saya menegaskan kembali bahwa RT saat ini adalah tidak-tidak untuk proyek yang memiliki modul yang tidak dirancang untuk inisialisasi multithreaded, lihat tiket Sage

Juga, komentar tentang masalah umum dengan RT saat ini: ini memicu pengimporan multi-utas modul Python saat melakukan penyelesaian tab. Kami sangat meragukan keamanannya.

Last but not least - mengingat penyelesaian tab IPython menyebabkan segfault, bagaimana dengan cara untuk pengujian non-interaktifnya?

@jonathanslenders apakah Anda mengalami masalah dengan penyelesaian yang berjalan di utas terpisah? Apakah ada opsi untuk membuatnya berjalan secara sinkron?

Hai @takluyver ,

Maaf untuk jawaban yang terlambat. Saya menikah bulan lalu, jadi saya offline untuk sementara waktu. ;)

Saya sedang mengerjakan Prompt_toolkit 2.0 yang sudah mendukung penyelesaian sinkron (di utas utama) dan asinkron (di utas lain). Saya telah mengerjakan 2.0 selama hampir satu tahun dan berharap untuk merilisnya dalam beberapa bulan.

Untuk penyelesaian sinkron, Anda harus ingat bahwa jika penyempurna tidak super cepat, ini akan menyebabkan penundaan setelah setiap penekanan tombol (jika Anda telah menyelesaikan saat mengetik). Saya percaya bahwa Jedi misalnya tidak super cepat.

Saya tahu bahwa perpustakaan tertentu memiliki beberapa masalah dengan penyelesaian asinkron. Saya pikir kita harus mendorong penulis perpustakaan ini untuk memastikan bahwa mengimpor mereka di tempat pertama dapat dilakukan dari utas apa pun. Di masa mendatang, saya akan menjadikannya opsi untuk menjalankan sinkronisasi penyelesaian atau asinkron, tetapi masih lebih suka memiliki penyelesaian asinkron secara default. Itu membuat pengalaman pengguna jauh lebih baik.

Pada Sabtu, 21 Okt 2017 jam 14:47, Jonathan Slenders < [email protected]

menulis:

Saya tahu bahwa perpustakaan tertentu memiliki beberapa masalah dengan asinkron
penyelesaian. Saya pikir kita harus mendorong para penulis perpustakaan ini untuk
pastikan mengimpornya sejak awal dapat dilakukan dari mana saja
benang.

IMHO itu angan-angan bahwa ini selalu mudah untuk dicapai.
Ada perpustakaan Python yang pada dasarnya membungkus ke-3 yang sangat kompleks
kode party, dan perubahan yang diperlukan untuk inisialisasi thread-safe harus
dilakukan di hulu.
Contoh kongkrit kita membenturkan kepala
adalah Maxima dijalankan dalam (tertanam ke dalam Python) sistem Lisp ECL.
Yang terakhir, seperti semua Lisps, membutuhkan pengumpul sampah, dan menggunakan BoehmGC . Pada beberapa platform yang terakhir harus
diinisialisasi di utas utama --- atau dulu, misalnya untuk
FreeBSD, sampai saya menunjukkannya, dan dengan cepat diperbaiki . Seperti yang dapat Anda bayangkan, di tempat lain
kasus seseorang bisa benar-benar kurang beruntung dengan perbaikan seperti itu, karena itu membutuhkan ahli
pengetahuan tentang sistem yang cukup rumit.

Dan ada beberapa masalah yang harus diselesaikan, salah satunya adalah dalam
skenario utas tunggal perpustakaan dapat melakukan penanganan sinyalnya sendiri, sedangkan
dalam skenario multi-utas penanganan sinyal harus terpusat. NS
lainnya, bahkan lebih sulit untuk diselesaikan, adalah bahwa kode pihak ke-3 itu mungkin tidak
aman untuk benang.
(kembali ke contoh di atas, kita melihat semua ini...)

Tampaknya pilihan terbaik adalah
agar PT melakukan semua impor di utas utama --- saya tidak tahu apakah
itu mudah atau bahkan layak untuk diterapkan.

Akhirnya, izinkan saya menunjukkan bahwa sebenarnya PT melakukan pengimporan multithreaded.
Karena mengimpor adalah hambatan awal untuk sistem besar, ini sangat
menggoda untuk mengizinkan pengimporan multithread.
Saya sangat ingin mendengar apa yang akan dikatakan orang-orang CPython tentangnya; Saya
tidak akan terkejut jika jawabannya adalah bahwa itu tidak boleh dilakukan.

PS. Saya tidak bermaksud merusak bulan madu Anda, selamat :-)

Selamat! Tentu saja tidak perlu meminta maaf - kami mendapatkan perpustakaan Anda yang luar biasa secara gratis, jadi dukungan apa pun harus sesuai dan kapan pun Anda mau. Doa terbaik untuk Anda dan pasangan.

Saya pikir kami mungkin akan beralih ke penyelesaian sinkron saat tersedia. Kami tidak menggunakan complete-as-you-type, karena kami mengaktifkan fitur pencarian riwayat yang saling eksklusif dengan itu.