Ipython: Karakter aneh setelah impor pertama

Hum Saya telah melihat yang ini tetapi dengan ^[[43;1R , tetapi saya berasumsi itu karena saya menguasai emulator terminal saya. Tidak yakin dari mana ini berasal

Saya telah melihat hal serupa di https://github.com/jonathanslenders/pymux terbaru (tidak dirilis, menggunakan Prompt-toolkit 2). Mungkin @jonathanslenders punya ide?

Saya mendapatkan hal yang sama:

$ ipython
Python 3.6.5 (default, Mar 30 2018, 06:41:53) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.0.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import os                                                                                             

^[[19;1RIn [2]:

Jika saya kemudian mencoba menyelesaikan tab:

In [2]: os.p                                                                                                  
os.pardir         os.pathconf       os.pathsep        os.popen          os.putenv         
os.path           os.pathconf_names os.pipe           os.pread          os.pwrite         
^[[19;1RIn [2]: os.p

Ini membuat penyelesaian tab hampir tidak dapat digunakan.

Mungkinkah ini diperbaiki dengan komit berikut: https://github.com/jonathanslenders/python-prompt-toolkit/commit/e226d640177aa1d2cf293e4de382f171586173a2 ?
Itu digabungkan dalam master prompt_toolkit, tapi saya akan merilis prompt_toolkit 2.0 baru yang menyertakannya.

Saya menginstal prompt-toolkit dari master dan masalahnya tampaknya masih ada, tetapi saya tidak yakin apakah ada hal lain yang perlu dilakukan di sisi ipython.

Tidak, saya cukup yakin ini bukan IPython. Saya akan mencoba mereproduksi dengan iterm2

Saya yakin saya tidak memahami kerumitan di sini, tetapi hanya untuk informasi, ini memang terjadi dengan IPython 7.0 dan 7.1, dan tidak terjadi dengan 6.0 atau 6.5, pengujian di virtualenv yang sama.

Bisakah Anda memposting di terminal mana Anda melihatnya?
Saya dapat mereproduksi di iTerm2 – 3.2.1beta6 – osx; alacritty v0.2.0-35-ga53cabf osx, tetapi tidak pada terminal.app macos kosong (sierra 10.12.6)

Mungkinkah ketidakcocokan antara fitur terminal yang diiklankan dan apa yang sebenarnya dapat mereka lakukan?

Itu juga tidak dapat direproduksi (bagi saya) dengan ipython --colors=nocolor

Buka Terminal.app di High Sierra 10.13.6 . nocolor tidak memperbaikinya untuk saya.

Itu juga tidak dapat direproduksi (bagi saya) dengan ipython --colors=nocolor

Gores itu, tampaknya acak, tetapi memang, nocolor tidak memperbaikinya.

Bisakah kalian mencoba dengan menghapus manajer konteks patch_stdout ?

Jika saya menghapusnya, itu _tampak_ baik-baik saja bagi saya, dan jika saya ekstra flush stdout saya mendapatkan masalah dua kali ..

Menghapus manajer konteks tampaknya memperbaikinya untuk saya.

Ini terjadi pada saya baik di macOS Terminal.app dan di iTerm2. Namun, karakter tersebut muncul cukup konsisten di iTerm2 3.2.1beta. Tadi pagi saya upgrade ke 3.2.2beta1 dan sekarang karakternya seperti muncul dan langsung hilang, diganti dengan prompt iPython biasa. Tapi setidaknya dalam satu kasus karakternya gigih, saya tidak yakin apa bedanya.

Yup, memperbaikinya untuk saya juga. Efeknya selalu konsisten bagi saya.

@jonathanslenders mungkinkah patch stdout memiliki kondisi balapan dan stdout/err dipulihkan, dan mulai ditulis, sebelum flush terjadi?

Parameter raw dari patch_stdout tampaknya juga tidak ke mana-mana dalam kode ptk.

Jadi ada alasan untuk memiliki ini, atau jika tidak, mencetak di utas latar belakang akan mengacaukan rendering, tetapi tampaknya (bagi saya), itu adalah kondisi balapan antara membilas stderr/out yang ditangkap dan mengembalikan ke nilai awalnya.

Tidak yakin apakah Anda melokalkan bug atau masih bereksperimen tetapi untuk informasi Anda:

• macOS 10.13.6
• iTerm 3.2.1 - selalu menampilkan ^[[41;1R setelah input pertama (impor, ekspresi, bahkan baris kosong)
• Terminal.app 2.8.2 (404) - berfungsi dengan baik!

Python 3.7.0 (default, Sep 18 2018, 18:47:22)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.0.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]:

^[[41;1RIn [1]:

Saya juga mendapatkan ini (macOS 10.11.6, iTerm 3.2.0beta5) sangat sering, meskipun tidak 100% dari waktu, dan dengan urutan 43;1R .

Python 3.7.0 (default, Jun 29 2018, 20:13:53)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.0.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import sqlalchemy

^[[43;1RIn [2]:

Ya, yang satu ini benar-benar membunuhku. Saya akan menurunkan versi, tetapi itu merusak notebook Jupyter. Bagi saya, penyelesaian tab kurang lebih benar-benar rusak, karena karakter ini sangat sering muncul.

Sayangnya readline bukanlah pilihan saat ini: https://github.com/ipython/rlipython/issues/21

Tidak ada perubahan menjalankan master prompt_toolkit (versi 2.0.5).

Saya bisa mereproduksinya.

iTerm2 build 3.2.3 (saya pikir yang terbaru), IPython 7.0.1, Python 3.6.1.

Saya memiliki bug dengan Python 3.6.3 di Ubuntu, dan itu menghilang dengan Python 3.7, meskipun saya dapat melihat beberapa gangguan (seperti karakter dicetak dan kemudian dihapus dengan cepat).

Saya memiliki perbaikan di sini: https://github.com/jonathanslenders/python-prompt-toolkit/commit/09de545476be985b95ae2690ef8393efdd65b7e5

Sebenarnya apa yang Anda lihat dalam komit ini adalah dua perbaikan individual yang keduanya akan menyelesaikan masalah (untuk apa yang dapat saya reproduksi).

• Untuk beberapa alasan, string kosong ditangkap dan ditulis ke stdout, tepat sebelum menerima input pertama. Ini memicu kode patch_stdout. Sebenarnya, tidak perlu melalui upaya menghapus prompt, dan menggambarnya lagi, hanya untuk mencetak string kosong. (Saya masih harus memeriksa mengapa ini benar-benar terjadi.)

• Perbaikan sebenarnya adalah menunggu respons CPR sebelum merender konten yang diambil. CPR bekerja secara asinkron. Kami meminta posisi kursor dengan menulis sesuatu ke stdout, dan kami menerima respons dari terminal di stdin. Selalu ada sedikit keterlambatan. Tetapi penting untuk menjaga terminal dalam mode RAW dan membaca input ini hingga respons ini tiba. Kami tidak melakukan itu, dan itu membuat respons terminal sendiri dengan posisi kursor.

Waktunya seharusnya sedikit berbeda antar terminal, tetapi saya kira ini harus dilakukan.

Bisakah Anda semua mencoba dengan komit prompt_toolkit terbaru? Jika berhasil, saya akan mendorong rilis baru.

Itu memperbaiki bug di sisi saya. Terima kasih @jonathanslenders !

Ya, terima kasih banyak, master terbaru juga memperbaikinya untuk saya.

Patch itu memperbaiki beberapa karakter [[39;1R saya alami juga. Terima kasih!

EDIT: Gores itu. Saya menguji versi yang salah. Ya, ini sepertinya memperbaikinya untuk saya juga.

Tidak, ini sepertinya tidak memperbaikinya untuk saya. Sebaliknya saya mendapatkan karakter yang berbeda

AlbireoProˇalbireo: Downloads » ipython                 (3.7.0 2.7.15)

In [1]: from can.interfaces.slcan import slcanBus

^[[21;1RIn [2]:

Bisakah Anda semua mencoba dengan komit prompt_toolkit terbaru? Jika berhasil, saya akan mendorong rilis baru.

bekerja untuk saya. Anda juga mengubah penanganan warna AFAICT, kami enggan mengandalkan pemetaan ansi ke kode ansi di beberapa tempat di IPython, saya akan memperbaikinya juga. Terima kasih!

@Carreau : Saya baru saja mendorong Prompt_toolkit 2.0.6.
Apakah IPython mengharapkan urutan RRGGBB tertentu dipetakan ke warna ANSI tertentu, bahkan dalam mode 256warna?

By the way @Carreau , salah satu fitur prompt_toolkit sekarang adalah kemampuan untuk menambah/mengurangi kecerahan warna. Hal ini memudahkan untuk menyesuaikan dengan terminal dengan latar belakang terang atau gelap. Saya telah menambahkan ini ke menu ptpython untuk pengujian (interaktif) dan berfungsi dengan cukup baik.

mengharapkan

Saya tidak akan mengatakan "mengharapkan" tetapi tema tampaknya memiliki campuran #ansixxx dan #00ff00 yang terlihat bagus bersama, dan dengan 2.0.6 sedikit lebih kuat dalam perbedaannya.

Saya pikir kita hanya perlu lebih banyak konsistensi apakah kita menggunakan #ansi atau #hex .

Saya akan melihat opsi kecerahan di beberapa titik. Saya baru saja memulai posisi baru beberapa minggu yang lalu dan memiliki sedikit waktu untuk mengembangkan IPython/jupyter itu sendiri.

Menarik, tapi masuk akal. Ketika sebuah warna didefinisikan sebagai #00ff00, saya melihat warna terdekat dari 256 palet warna, tetapi saya mengecualikan 16 warna ansi. Yang berarti dibutuhkan paling dekat dari 240 warna yang tersisa.

Alasannya adalah bahwa orang-orang hari ini sering memiliki skema warna khusus yang ditentukan untuk warna ANSI - tetapi tidak untuk 240 warna yang tersisa. Jadi, sementara itu bisa sedikit berbeda dalam situasi Anda, itu sebenarnya bisa lebih dekat dengan warna sebenarnya untuk orang lain.

Berikut adalah contoh bagaimana warna ANSI dasar dirender di terminal yang berbeda:
https://en.wikipedia.org/wiki/ANSI_escape_code#Colors

penutupan sebagai hulu tetap