Ipython: Conclusões de guia para caminhos quebrados novamente em 7.2.0

Eu tenho o mesmo problema, ipython 7.2.0.

Fazer downgrade para ipython == 7.1.1 pareceu funcionar como uma correção para mim.

Alguém poderia dizer se a ativação de jedi ajudou seu fluxo de trabalho e, se ajudou, eu gostaria de saber como?

Certamente tornou minha vida muito mais difícil: sem conclusão em vários níveis, sem conclusão de pasta, nem posso usar o preenchimento automático antes de executar a célula ( df = pd.DataFrame(); df.val<TAB> falha)

O bug certamente tornou minha vida muito mais difícil também.

O preenchimento automático é provavelmente um dos recursos mais importantes de um shell interativo. Existe uma maneira de o jedi e a autocompletar de caminhos coexistirem?
Algumas heurísticas muito simples na decisão de usar jedi ou a conclusão legada ajudarão muito: se alguém estiver em uma string, é improvável que se queira nomes do namespace atual.

Para aqueles que tiveram problemas com o downgrade, achei o comentário de @ivirshup muito útil - desativar o autocomplete jedi na configuração do ipython. Se ainda não o fez, você pode gerar ipython_config.py com:

# Generate config
ipython profile create
# Edit config file in vim
vim .ipython/profile_default/ipython_kernel_config.py 

E mude c.IPCompleter.use_jedi = False em ipython_config.py

[O completador jedi] certamente tornou minha vida muito mais difícil: sem conclusão em vários níveis, sem conclusão de pasta, [...]

Não não não. Não é o Jedi Completer que faz isso. Existem vários completadores e você está descrevendo que o completador errado foi selecionado porque o código de seleção do completador foi quebrado. E tocar na lista de completadores habilitando o jedi descobriu esse bug. @takluyver descreve o problema em https://github.com/ipython/ipython/pull/10996#issuecomment -378288569.

Desativar o jedi novamente é uma solução temporária, mas corrigir o código de seleção de complemento (# 11064 eu acho) seria uma solução muito melhor.

Meu entendimento é que todos os completadores estão trabalhando ao mesmo tempo. Os completadores são definidos aqui e todos são usados ao mesmo tempo . A lista matches (o resultado do autocompletar) conterá a concatenação de todos os resultados completadores, e o completador file_matches ainda faz parte dela.

Portanto, o preenchimento do caminho / nome do arquivo não é "quebrado" quando o jedi está habilitado, mas há tantos resultados (vindos do jedi) que você não consegue mais ver a correspondência do caminho do arquivo.

Minha primeira ideia para uma correção seria desativar o preenchimento automático de Jedi ao digitar uma string? Isso funcionaria?
A única coisa que não funcionaria é o preenchimento automático ao executar o código com eval ou exec , mas acho que não podemos corrigir todos os casos de uso. E parece que algumas pessoas gostam do preenchimento automático do caminho do arquivo.

EDIT: Lendo o outro problema que você vinculou a @ flying-sheep # 11064, entendi que já existe uma lógica para não usar jedi ao digitar uma string, mas está quebrado?

Apenas para ilustrar o que estou dizendo. Ambas as capturas de tela foram feitas usando jedi, você vê que o preenchimento automático do caminho ainda funciona, você só precisa digitar um pouco mais porque há mais correspondências.

Geralmente esse é o meu problema: digitar um pouco ajuda, mas nem sempre é uma opção se você não souber a primeira letra do arquivo. Mesmo se você claramente começou a digitar um caminho, depois de cada "/" o completador "redefine" para o modo padrão de me mostrar abs (), all () e outros embutidos.

É um grande problema se você tiver caminhos longos com algumas pastas aninhadas. O preenchimento automático do Bash apenas adicionaria coisas na "guia". Com o ipython autocomplete atual, você tem que lembrar a primeira letra ou algumas letras de cada pasta / arquivo, digitá-la e, em seguida, ainda percorrer alguns recursos antes de encontrar seu arquivo / pasta.

Se houvesse uma maneira de remover todos os builtins do autocompletar e toda a magia do ipython - já seria muito melhor!

Eu sei como digitar 'abs', e a maioria de nós pode digitá-lo várias vezes mais rápido do que selecioná-lo na lista de preenchimento automático. Não tenho certeza se há uma boa razão para isso, e outros embutidos de 3-4 letras, estar lá em primeiro lugar! Idealmente, se houvesse uma maneira de editar a lista de builtins, eu apenas deixaria alguns nomes longos que uso, como DepercationWarning, e me livraria de todo o resto.

Basta olhar para o caso de uso na imagem: Por que eu iria querer digitar um nome de objeto Python dentro de uma string literal?

Posso encontrar um caso de uso simples:

exec("print(abs(-3))", [globals()])

Talvez seja um caso de uso menos comum, mas pode acontecer. Eu concordaria que a conclusão do caminho é mais importante do que este caso de uso para a maioria dos usuários.

Sim, é uma possibilidade, e algumas pessoas confiam muito nos executivos.

Idealmente, o preenchimento automático deve detectar que está em um modo de nome de arquivo e, a partir daí, funcionar como um preenchimento de tab bash normal. Um bom proxy começa com "/", "./" ou "C:" "D:" etc.

É ainda menos provável que a string começando com essas variáveis ​​contenha expressões Python válidas.

Tenho certeza que alguém pode fazer um exemplo de a = "C:print(abs(-3))"; exec(a[2:]) mas isso é muito improvável.

Sim, na verdade, o código deve pular a conclusão do jedi quando você está digitando uma string. Veja esta linha: https://github.com/ipython/ipython/blob/65778adec13a65f82c5d2bab123e7a63516702c8/IPython/core/completer.py#L1375
E se baseia na lógica de análise interna do Jedi para tentar descobrir se estamos em uma string ou não.
Testei um pouco esse código e descobri que ele está um pouco quebrado, por exemplo, ao digitar path = " ele verá que você está em uma string, mas não com path = "./ . Acho que podemos encontrar uma solução melhor usando tokenize .

É porque Jedi não acha que é um ErrorLeaf, ou é porque voltar por dois nós é insuficiente?

Não tenho certeza, e rapidamente mudei minha mente para tokenize porque não gostei do fato de que ele depende de coisas jedi internas (API privada).

tokenize também tem seu problema. E se a célula gerar um IndentationError ou SyntaxError antes da abertura da string?

Você pode precisar retroceder as linhas gradualmente, mas então você sempre espera um erro perto do cursor devido à declaração de string incompleta?

Com o tokenize, estou pensando em uma lógica simples como se fosse inputtransformer2.py . Existe alguma lógica para saber se o usuário está digitando uma lista ou um dicionário no terminal, para que ao pressionar enter você não execute o código, coloque uma nova linha:


Talvez possamos tentar algo equivalente com os caracteres " e ' (posso tentar criar um PR).

Outra ideia também poderia ser usar regexp, mas eu seria inútil neste caso: P

tokenize também tem seu problema. E se a célula gerar um IndentationError ou SyntaxError antes da abertura da string

Eu acho que simplesmente não iria completar ... Qual é o comportamento atual? O autocompletar ainda funciona quando você tem um SyntaxError em seu código? Devemos verificar

Mesmo problema após atualizar para 7.3.0.

Sim, funciona quando você tem um SyntaxError.

IIRC tokenize é bastante robusto sobre erros de sintaxe - o tipo de trecho que você mostra ainda pode ser tokenizado corretamente, o erro só viria quando você tentasse entender os tokens.

Não tenho certeza do que faria com algo como uma string não terminada na linha anterior, o que pode ser um erro de sintaxe no nível de tokenização.

Problemas semelhantes com a última instalação do conda:

python                    3.7.3
ipykernel                 5.1.0              
ipython                   7.4.0           

Na verdade, não consigo completar o tab. Somente dentro de uma função (shift + double-tab) eu obtenho a conclusão da docstring. Sem conclusão de método em objetos. A digitação de caminhos dentro de strings funciona conforme o esperado, ou seja, nenhuma variável global listada.

O problema permanece no IPython 7.7.0 instalado via conda:

ipython                   7.7.0            py37h5ca1d4c_0    conda-forge
ipython_genutils          0.2.0                      py_1    conda-forge
jedi                      0.14.1                   py37_0    conda-forge
python                    3.7.3                h33d41f4_1    conda-forge

E assim será até que este problema e o # 10926 sejam encerrados. @ JeremySikes73 e eu demos alguma explicação sobre o que está errado, e tenho quase certeza de que o problema é o mesmo: todos os matchers de IPython retornam resultados, enquanto devemos a) executar apenas os relevantes ou b) adicionar código aos matchers que tornam eles não retornam nada quando seus resultados seriam irrelevantes.

Obrigado por tentar ajudar, mas acho que é mais produtivo ler # 10926, mergulhar no código e descobrir como melhorar a situação do que dizer “ainda é um problema”.

Procura-se ajuda da tag

conclusão da guia da tag

Para aqueles que tiveram problemas com o downgrade, achei o comentário de @ivirshup muito útil - desativar o autocomplete jedi na configuração do ipython. Se ainda não o fez, você pode gerar ipython_config.py com:

# Generate config
ipython profile create
# Edit config file in vim
vim .ipython/profile_default/ipython_kernel_config.py 

E mude c.IPCompleter.use_jedi = False em ipython_config.py

Qual arquivo editar? ipython_kernel_config.py ou ipython_config.py ?

Uma solução temporária para esse problema é acrescentar uma segunda barra após pressionar a tabulação.

Depois de digitar '/<TAB>

Depois de digitar /

Depois que um item é selecionado, haverá apenas uma única barra como separador:

Após pressionar voltar

Observe que adicionar a segunda barra antes de pressionar a guia não altera o menu pop-up.

Eu atualizei para a versão mais recente do ipython a partir de hoje (7.11.0), e o problema ainda persiste.

@ flying-sheep @augustogoulart Você está aberto para fazer solicitações sobre isso? (Quer dizer, a tag "helpwanted" sugere isso, mas não sou um contribuidor existente, então não tenho certeza das normas do desenvolvedor aqui.) Tenho algumas pequenas alterações na lógica na detecção de se estamos em uma string ou não , que, embora não seja uma solução perfeita, pelo menos faz um trabalho melhor em desligar o jedi.

Isso não corrige completamente o # 10926 ou isso, já que seria bom desligar (na minha opinião):

• a conclusão do arquivo corresponde quando em uma string de chave do dicionário
• a conclusão mágica corresponde quando em qualquer string

mas pelo menos desliga o jedi quando em uma corda, o que ajuda muito a tornar os meus próprios padrões de uso viáveis.

Eu também sou um contribuidor pequeno, mas aposto que eles gostariam de ajudar a consertar isso!