Ipython: Personagem estranho após a primeira importação

Hum, eu vi este, mas com ^[[43;1R , mas presumi que era devido ao fato de eu estar no mestre do meu emulador de terminal. Não tenho certeza de onde vem isso

Eu vi coisas semelhantes no último https://github.com/jonathanslenders/pymux (não lançado, usa prompt-toolkit 2). Talvez @jonathanslenders tenha alguma ideia?

Eu recebo o mesmo:

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

Se eu tentar completar a tabulação:

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

Isso torna o preenchimento da guia quase inutilizável.

É possível que isso tenha sido corrigido pelo seguinte commit: https://github.com/jonathanslenders/python-prompt-toolkit/commit/e226d640177aa1d2cf293e4de382f171586173a2 ?
Ele está mesclado no prompt_toolkit master, mas estou prestes a lançar um novo prompt_toolkit 2.0 que o inclui.

Eu instalei prompt-toolkit do master e o problema ainda parece estar lá, mas não tenho certeza se algo mais precisa ser feito no lado do ipython.

Não, tenho quase certeza de que não é IPython. Vou tentar reproduzir com iterm2

Tenho certeza que não estou entendendo as complexidades aqui, mas apenas para informação, isso ocorre com IPython 7.0 e 7.1, e não ocorre com 6.0 ou 6.5, testando no mesmo virtualenv.

Vocês podem postar em qual terminal o viram?
Consigo reproduzir no iTerm2 - 3.2.1beta6 - osx; alacritty v0.2.0-35-ga53cabf osx, mas não em macos terminal.app (sierra 10.12.6) nua

Poderia haver incompatibilidade entre os recursos anunciados do terminal e o que eles realmente podem fazer?

Também não é reproduzível (para mim) com ipython --colors=nocolor

Apenas Terminal.app vazio no High Sierra 10.13.6. nocolor não corrige isso para mim.

Também não é reproduzível (para mim) com ipython --colors=nocolor

Risque isso, parece ser aleatório, mas na verdade, a nocolor não corrigiu isso.

Vocês podem tentar remover este patch_stdout gerenciador de contexto?

Se eu removê-lo, ele _parece_ bom para mim, e se eu liberar extra stdout, recebo o problema duas vezes.

Remover o gerenciador de contexto parece consertar isso para mim.

Isso acontece comigo no macOS Terminal.app e no iTerm2. No entanto, o personagem apareceu de forma bastante consistente em iTerm2 3.2.1beta. Esta manhã eu atualizei para 3.2.2beta1 e agora o personagem parece aparecer e desaparecer imediatamente, substituído pelo prompt normal do iPython. Mas pelo menos em um caso o personagem foi persistente, não tenho certeza de qual foi a diferença.

Sim, conserta para mim também. O efeito sempre foi consistente para mim.

@jonathanslenders será que o patch stdout teve uma condição de corrida e que o stdout / err foi restaurado e começou a ser gravado antes que o flush acontecesse?

O parâmetro raw de patch_stdout parece ir a lugar nenhum também no código ptk.

Portanto, há uma razão para ter isso, ou de outra forma imprimir em threads de fundo bagunçaria a renderização, mas parece (para mim) que é uma condição de corrida entre liberar stderr / out capturado e restaurar seu valor inicial.

Não tenho certeza se você localizou o bug ou ainda está experimentando, mas para sua informação:

• macOS 10.13.6
• iTerm 3.2.1 - mostra sempre ^[[41;1R após a primeira entrada (importação, expressão, até mesmo linha em branco)
• Terminal.app 2.8.2 (404) - funciona bem!

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

Também estou recebendo isso (macOS 10.11.6, iTerm 3.2.0beta5) com muita frequência, embora não 100% do tempo, e com a sequência 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]:

Sim, este está realmente me matando. Eu faria o downgrade, mas isso quebra os notebooks Jupyter. Para mim, o preenchimento de tabulação está mais ou menos quebrado, porque esses caracteres aparecem com muita frequência.

Infelizmente readline não é uma opção no momento: https://github.com/ipython/rlipython/issues/21

Nenhuma mudança executando o mestre atual de prompt_toolkit (versão 2.0.5).

Eu posso reproduzi-lo.

iTerm2 build 3.2.3 (acho que o mais recente), IPython 7.0.1, Python 3.6.1.

Eu tive o bug com Python 3.6.3 no Ubuntu, e ele desapareceu com o Python 3.7, embora eu possa ver algumas falhas (como os caracteres são impressos e depois removidos rapidamente).

Eu tenho uma correção aqui: https://github.com/jonathanslenders/python-prompt-toolkit/commit/09de545476be985b95ae2690ef8393efdd65b7e5

Na verdade, o que você vê neste commit são duas correções individuais que resolveriam o problema (pelo que eu poderia reproduzir).

• Por algum motivo, uma string vazia é capturada e gravada em stdout, logo antes de aceitar a primeira entrada. Isso acionou o código patch_stdout. Na verdade, não havia necessidade de se esforçar para apagar o prompt e desenhá-lo novamente, apenas para imprimir uma string vazia. (Ainda tenho que verificar por que isso está realmente acontecendo.)

• A verdadeira correção é aguardar as respostas do CPR antes de renderizar o conteúdo capturado. CPR funciona de forma assíncrona. Pedimos a posição do cursor escrevendo algo em stdout e recebemos a resposta do terminal em stdin. Sempre há um pequeno atraso. Mas é importante manter o terminal no modo RAW e ler esta entrada até que esta resposta chegue. Não fizemos isso, e ele gerou a própria resposta do terminal com a posição do cursor.

O tempo deveria ter sido um pouco diferente entre os terminais, mas acho que isso deve bastar.

Vocês poderiam tentar com o último commit do prompt_toolkit? Se funcionar, enviarei um novo lançamento.

Isso corrige o bug do meu lado. Obrigado @jonathanslenders !

Sim, muito obrigado, o último mestre corrige isso para mim também.

Esse patch corrige alguns [[39;1R chars que eu estava comendo também. Obrigado!

EDIT: risque isso. Eu estava testando a versão errada. Sim, isso parece consertar para mim também.

Não, isso não parece resolver para mim. Em vez disso, recebo um personagem diferente

AlbireoProˇalbireo: Downloads » ipython                 (3.7.0 2.7.15)

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

^[[21;1RIn [2]:

Vocês poderiam tentar com o último commit do prompt_toolkit? Se funcionar, enviarei um novo lançamento.

funciona para mim. Você também altera a manipulação das cores AFAICT, estávamos involuntariamente contando com o mapeamento ansi para o código ansi em alguns lugares no IPython. Vou consertar isso também. Obrigado !

@Carreau : Acabei de enviar o prompt_toolkit 2.0.6.
O IPython espera que certas sequências RRGGBB sejam mapeadas para certas cores ANSI, mesmo no modo 256 cores?

A propósito, @Carreau , um recurso do prompt_toolkit agora é a capacidade de aumentar / diminuir o brilho das cores. Isso facilita o ajuste a terminais com fundo claro ou escuro. Eu adicionei isso ao menu do ptpython para teste (interativamente) e funciona muito bem.

Espero

Eu não diria "esperar", mas os temas parecem ter uma mistura de #ansixxx e #00ff00 que ficavam bem juntos e com 2.0.6 são um pouco mais fortes em suas diferenças.

Acho que só precisamos de mais consistências quanto ao uso de #ansi ou #hex .

Vou olhar as opções de brilho em algum momento. Acabei de começar uma nova posição há algumas semanas e tenho um pouco menos de tempo para desenvolver o próprio IPython / jupyter.

Interessante, mas faz sentido. Quando uma cor é definida como # 00ff00, vejo a cor mais próxima na paleta de 256 cores, mas estou excluindo as 16 cores ansi. O que significa que é o mais próximo das 240 cores restantes.

O motivo é que as pessoas hoje em dia costumam ter esquemas de cores personalizados definidos para as cores ANSI - mas não para as 240 cores restantes. Portanto, embora possa ser um pouco estranho na sua situação, pode, na verdade, ser muito mais próximo da cor real para outras pessoas.

Aqui está um exemplo de como as cores ANSI básicas são renderizadas em terminais diferentes:
https://en.wikipedia.org/wiki/ANSI_escape_code#Colors

fechando como fixo a montante