Ipython: Personaje extraño después de la primera importación

Hum, he visto este pero con ^[[43;1R , pero asumí que se debía a que estaba en el maestro de mi emulador de terminal. No estoy seguro de donde viene esto

He visto cosas similares en el último https://github.com/jonathanslenders/pymux (no publicado, usa el kit de herramientas prompt 2). ¿Quizás @jonathanslenders tiene alguna idea?

Obtengo lo mismo:

$ 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]:

Si luego intento completar la pestaña:

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

Esto hace que la finalización de pestañas sea casi inutilizable.

¿Es posible que esto se haya solucionado con la siguiente confirmación: https://github.com/jonathanslenders/python-prompt-toolkit/commit/e226d640177aa1d2cf293e4de382f171586173a2 ?
Está fusionado en el maestro prompt_toolkit, pero estoy a punto de lanzar un nuevo prompt_toolkit 2.0 que lo incluye.

Instalé prompt-toolkit del maestro y el problema todavía parece estar ahí, pero no estoy seguro de si es necesario hacer algo más en el lado de ipython.

No, estoy bastante seguro de que esto no es IPython. Intentaré reproducir con iterm2

Estoy seguro de que no entiendo las complejidades aquí, pero solo para información, esto ocurre con IPython 7.0 y 7.1, y no ocurre con 6.0 o 6.5, probando en el mismo virtualenv.

¿Pueden todos publicar en qué terminal lo han visto?
Puedo reproducir en iTerm2 - 3.2.1beta6 - osx; alacritty v0.2.0-35-ga53cabf osx, pero no en macos terminal.app desnudo (sierra 10.12.6)

¿Podría haber una discrepancia entre las características anunciadas del terminal y lo que realmente pueden hacer?

Tampoco es reproducible (para mí) con ipython --colors=nocolor

Solo Terminal.app desnudo en High Sierra 10.13.6. nocolor no me lo soluciona.

Tampoco es reproducible (para mí) con ipython --colors=nocolor

Borre eso, parece ser aleatorio, pero de hecho, nocolor no lo solucionó.

¿Pueden intentar eliminar este administrador de contexto

Si lo elimino, me parece que está bien, y si hago un lavado adicional estándar, obtengo el problema dos veces.

Eliminar el administrador de contexto parece solucionarlo para mí.

Esto me sucede en macOS Terminal.app y en iTerm2. Sin embargo, el personaje apareció de manera bastante consistente en iTerm2 3.2.1beta. Esta mañana actualicé a 3.2.2beta1 y ahora el personaje parece aparecer y desaparecer inmediatamente, reemplazado por el indicador normal de iPython. Pero al menos en un caso el personaje ha sido persistente, no estoy seguro de cuál fue la diferencia.

Sí, me lo arregla también. El efecto siempre fue constante para mí.

@jonathanslenders ¿ podría ser que el parche stdout tenía una condición de carrera y que stdout / err se restauran y comienzan a escribirse antes de que ocurra el vaciado?

El parámetro raw de patch_stdout tampoco parece ir a ninguna parte en el código ptk.

Entonces, hay una razón para tener esto, o de lo contrario, la impresión en subprocesos en segundo plano estropearía la representación, pero me parece (a mí) que es una condición de carrera entre el vaciado de stderr / out capturado y la restauración a su valor inicial.

No estoy seguro si localizó el error o aún está experimentando, pero para su información:

• macOS 10.13.6
• iTerm 3.2.1: muestra siempre ^[[41;1R después de la primera entrada (importación, expresión, incluso línea en blanco)
• Terminal.app 2.8.2 (404) - ¡funciona bien!

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]:

También obtengo esto (macOS 10.11.6, iTerm 3.2.0beta5) con mucha frecuencia, aunque no el 100% del tiempo, y con la secuencia 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]:

Sí, este realmente me está matando. Bajaría la calificación, pero eso rompe los cuadernos de Jupyter. Para mí, la finalización de tabulación está más o menos completamente rota porque estos caracteres aparecen con mucha frecuencia.

Lamentablemente, readline no es una opción en este momento: https://github.com/ipython/rlipython/issues/21

Sin cambios al ejecutar el maestro actual de prompt_toolkit (versión 2.0.5).

Puedo reproducirlo.

iTerm2 build 3.2.3 (creo que el último), IPython 7.0.1, Python 3.6.1.

Tuve el error con Python 3.6.3 en Ubuntu y desapareció con Python 3.7, aunque puedo ver algunos fallos (como que los caracteres se imprimen y luego se eliminan rápidamente).

Tengo una solución aquí: https://github.com/jonathanslenders/python-prompt-toolkit/commit/09de545476be985b95ae2690ef8393efdd65b7e5

En realidad, lo que ves en esta confirmación son dos correcciones individuales que resolverían el problema (por lo que podría reproducir).

• Por alguna razón, una cadena vacía se captura y se escribe en stdout, justo antes de aceptar la primera entrada. Esto activó el código patch_stdout. En realidad, no hubo necesidad de realizar el esfuerzo de borrar el mensaje y volver a dibujarlo, solo para imprimir una cadena vacía. (Todavía tengo que comprobar por qué está sucediendo esto realmente).

• La verdadera solución es esperar las respuestas de RCP antes de reproducir el contenido capturado. La RCP funciona de forma asincrónica. Solicitamos la posición del cursor escribiendo algo en stdout, y recibimos la respuesta del terminal en stdin. Siempre hay un pequeño retraso. Pero es importante mantener el terminal en modo RAW y leer esta entrada hasta que llegue esta respuesta. No hicimos eso, y mostró la propia respuesta del terminal con la posición del cursor.

La sincronización debería haber sido ligeramente diferente entre terminales, pero supongo que esto debería ser suficiente.

¿Podrías intentarlo con la última confirmación de prompt_toolkit? Si funciona, lanzaré una nueva versión.

Eso arregla el error de mi lado. ¡Gracias @jonathanslenders !

Sí, muchas gracias, el último maestro me lo corrige también.

Ese parche corrige algunos caracteres [[39;1R yo también tenía. ¡Gracias!

EDITAR: Tacha eso. Estaba probando la versión incorrecta. Sí, esto también parece arreglarlo para mí.

No, esto no parece arreglarlo para mí. En cambio, obtengo un personaje diferente

AlbireoProˇalbireo: Downloads » ipython                 (3.7.0 2.7.15)

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

^[[21;1RIn [2]:

¿Podrías intentarlo con la última confirmación de prompt_toolkit? Si funciona, lanzaré una nueva versión.

funciona para mi. También cambia el manejo de los colores AFAICT, confiamos involuntariamente en el mapeo ansi al código ansi en algunos lugares de IPython, también lo arreglaré. Gracias !

@Carreau : Acabo de presionar prompt_toolkit 2.0.6.
¿IPython espera que ciertas secuencias RRGGBB se asignen a ciertos colores ANSI, incluso en el modo de 256 colores?

Por cierto @Carreau , una característica de prompt_toolkit ahora es la capacidad de aumentar / disminuir el brillo de los colores. Esto facilita el ajuste a terminales con fondo claro u oscuro. He agregado esto al menú de ptpython para probar (de forma interactiva) y funciona bastante bien.

suponer

No diría "esperar" pero los temas parecen tener una mezcla de #ansixxx y #00ff00 que se veían bien juntos, y con 2.0.6 son un poco más fuertes en sus diferencias.

Creo que solo necesitamos más consistencias en cuanto a si usamos #ansi o #hex .

Veré las opciones de brillo en algún momento. Acabo de comenzar una nueva posición hace unas semanas y tengo un poco menos de tiempo para desarrollar IPython / jupyter.

Interesante, pero tiene sentido. Cuando un color se define como # 00ff00, miro el color más cercano de la paleta de 256 colores, pero estoy excluyendo los 16 colores ansi. Lo que significa que toma el más cercano de los 240 colores restantes.

La razón es que la gente en estos días a menudo tiene definidos esquemas de color personalizados para los colores ANSI, pero no para los 240 colores restantes. Entonces, aunque podría estar un poco apagado en su situación, en realidad podría estar mucho más cerca del color real para otras personas.

A continuación, se muestra un ejemplo de cómo se representan los colores ANSI básicos en diferentes terminales:
https://en.wikipedia.org/wiki/ANSI_escape_code#Colors

cerrando como fijo aguas arriba