Ipython: falha test_history

Criado em 8 out. 2018 · 16Comentários · Fonte: ipython/ipython

Estou tentando empacotar o ipython 7.0.1 para openSUSE e estou recebendo o seguinte erro nos testes de unidade:

======================================================================
FAIL: IPython.core.tests.test_history.test_history
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/usr/lib/python3.6/site-packages/IPython/core/tests/test_history.py", line 113, in test_history
    newhist[3]])
AssertionError: Lists differ: [(1, [51 chars]rn test'), (1, 3, "b='€Æ¾÷ß'"), (2, 1, 'z=5'), (2, 3, "k='p'")] != [(1, [51 chars]rn test'), (1, 3, "b='€Æ¾÷ß'"), (2, 3, "k='p'"), (2, 4, 'z=5')]

First differing element 3:
(2, 1, 'z=5')
(2, 3, "k='p'")

  [(1, 1, 'a=1'),
   (1, 2, 'def f():\n    test = 1\n    return test'),
   (1, 3, "b='€Æ¾÷ß'"),
-  (2, 1, 'z=5'),
-  (2, 3, "k='p'")]
?                 ^

+  (2, 3, "k='p'"),
?                 ^

+  (2, 4, 'z=5')]
-------------------- >> begin captured stdout << ---------------------
def f():
    test = 1
    return test
b='€Æ¾÷ß'
The following commands were written to file `/tmp/tmphhgt1b7l/tmpsytny8bh/test4.py`:
a=1
def f():
    test = 1
    return test
b='€Æ¾÷ß'

--------------------- >> end captured stdout << ----------------------
    """Fail immediately, with the given message."""
>>  raise self.failureException('Lists differ: [(1, [51 chars]rn test\'), (1, 3, "b=\'€Æ¾÷ß\'"), (2, 1, \'z=5\'), (2, 3, "k=\'p\'")] != [(1, [51 chars]rn test\'), (1, 3, "b=\'€Æ¾÷ß\'"), (2, 3, "k=\'p\'"), (2, 4, \'z=5\')]\n\nFirst differing element 3:\n(2, 1, \'z=5\')\n(2, 3, "k=\'p\'")\n\n  [(1, 1, \'a=1\'),\n   (1, 2, \'def f():\\n    test = 1\\n    return test\'),\n   (1, 3, "b=\'€Æ¾÷ß\'"),\n-  (2, 1, \'z=5\'),\n-  (2, 3, "k=\'p\'")]\n?                 ^\n\n+  (2, 3, "k=\'p\'"),\n?                 ^\n\n+  (2, 4, \'z=5\')]')


----------------------------------------------------------------------

Parece que os dois últimos elementos da lista trocaram de lugar, mas não sei por que pode ser esse o caso.

EDITAR:

Provavelmente, podemos corrigir esse problema em duas etapas:

1) marque o teste como ignorar (ou falha conhecida) para o intervalo de versões do sqlite que parecem ser afetadas.
2) realmente descobrir se essa é uma mudança de comportamento que vale a pena corrigir ou se o teste deve ser atualizado de acordo.

Hacktoberfest help wanted

Fonte

toddrme2178

Comentários muito úteis

Acho que não tem sublinhado na base de código IPython.

Por exemplo, lá .

@dsblank , você já experimentou o RipGrep ? Muito bom: pule .git por padrão, pesquise recursivamente por padrão, destaque de cor e filtre por tipos de arquivo. Por exemplo, procure skipif apenas em arquivos Python:

$ rg <strong i="11">@skipif</strong> -tpy
IPython/extensions/tests/test_autoreload.py
133:    @skipif(sys.version_info < (3, 6))

IPython/core/tests/test_interactiveshell.py
531:    @skipif(not hasattr(signal, 'SIGALRM'))

IPython/lib/tests/test_latextools.py
47:<strong i="12">@skipif_not_matplotlib</strong>
62:<strong i="13">@skipif_not_matplotlib</strong>

IPython/lib/tests/test_display.py
182:<strong i="14">@skipif_not_numpy</strong>
 ~/dev/ipython[master ✗] $ rg <strong i="15">@skip_if</strong> -tpy
IPython/lib/tests/test_clipboard.py
7:<strong i="16">@skip_if_no_x11</strong>

IPython/utils/tests/test_path.py
102:<strong i="17">@skip_if_not_win32</strong>
117:<strong i="18">@skip_if_not_win32</strong>
157:<strong i="19">@skip_if_not_win32</strong>
377:    <strong i="20">@skip_if_not_win32</strong>
468:    <strong i="21">@skip_if_not_win32</strong>

... e 10x mais rápido na minha máquina.

Carreau em 15 out. 2018

👍3

Todos 16 comentários

Em qual versão do Python você está executando isso? Veja também a versão do sqlite.

Carreau em 10 out. 2018

Aqui estão as versões python e sqlite:

libsqlite3-0-3.25.0-1.1
python3-3.6.5-3.4

E alguns outros que acho que podem ser relevantes:

bash-4.4-107.1
coreutils-8.30-1.2
gcc8-8.2.1+r264010-1.1
gettext-runtime-mini-0.19.8.1-9.1
gettext-tools-mini-0.19.8.1-9.1
glibc-2.27-6.1
libdb-4_8-4.8.30-36.5
libgdbm5-1.14.1-1.6
libgdbm_compat4-1.14.1-1.6
libncurses6-6.1-6.5
libreadline7-7.0-2.1
libstdc++6-8.2.1+r264010-1.1
libzmq5-4.2.5-2.1
linux-glibc-devel-4.18-1.1
ncurses-utils-6.1-6.5
python3-ipython_genutils-0.2.0-2.1
python3-jedi-0.12.1-1.1
python3-jsonschema-2.6.0-2.2
python3-jupyter_client-5.2.3-4.1
python3-jupyter_core-4.4.0-3.1
python3-jupyter_ipyparallel-6.2.2-6.27
python3-jupyter_ipywidgets-7.4.2-10.1
python3-jupyter_nbconvert-5.4.0-15.11
python3-jupyter_nbformat-4.4.0-3.1
python3-jupyter_notebook-5.7.0-8.3
python3-jupyter_qtconsole-4.4.1-5.2
python3-jupyter_widgetsnbextension-3.4
python3-nose-1.3.7-10.1
python3-pexpect-4.6.0-2.1
python3-pyparsing-2.2.0-2.1
python3-pyzmq-17.1.2-1.1
python3-setuptools-40.4.3-1.1
python3-simplegeneric-0.8.1-8.4
python3-simplejson-3.16.1-1.1
python3-six-1.11.0-4.1
python3-terminado-0.8.1-3.1
python3-testpath-0.4.1-4.1
python3-traitlets-4.3.2-4.1
python3-wcwidth-0.1.7-2.1

toddrme2178 em 10 out. 2018

O problema também parece estar acontecendo na versão 6.5. Parece que o problema ocorreu pela primeira vez quando mudamos de sqlite3 3.24.0 para 3.25.0.

toddrme2178 em 13 out. 2018

na verdade, para z=5 o segundo número na tupla mudou. é o line number (AFAICT).

Então, por que 4 em vez de 1 ...? Pode ser que, quando solicitamos unique , solicitemos apenas uniq para a 3ª coluna e o sqlite esteja feliz em alterar seu comportamento interno e uniquificar antes de classificar, retornando assim a segunda iteração de z=5 ?

Carreau em 14 out. 2018

Eu senti falta disso. Mas eu realmente não sei nada sobre SQL, então não sei por que isso pode estar acontecendo. Confirmei que o problema ainda ocorre com o sqlite 3.25.2, a versão mais recente.

toddrme2178 em 14 out. 2018

Também não sou um especialista em SQL, pelo que posso dizer que as falhas no teste não são
crítico. Um marcador de "falha conhecida" ajudaria você a empacotar para o openSUSE ou
você prefere encontrar a causa raiz?

No domingo, 14 de outubro de 2018, 12h28, Todd [email protected] escreveu:

Eu senti falta disso. Mas eu realmente não sei nada sobre SQL, então não sei
porque isso pode estar acontecendo. Eu confirmei que o problema ainda ocorre com
sqlite 3.25.2, a versão mais recente.
-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ipython/ipython/issues/11372#issuecomment-429654816 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAUez9oGI6J02rTiDIfuzUCrpY71axO9ks5uk5B1gaJpZM4XMOVJ
.

Carreau em 14 out. 2018

Não sei a gravidade do bug, portanto, gostaria de seguir seu julgamento. Claro que uma solução real é preferível, mas se você acha que o problema é pequeno, podemos ir com uma falha conhecida por enquanto.

toddrme2178 em 14 out. 2018

@LucianaMarques você estava procurando por algo fácil, não deve ser muito difícil adicionar um "@skip_if" com uma condição como ... sqlite3.sqlite_version_info > (x, y, z)

Podemos adiar a correção para mais tarde.

Carreau em 15 out. 2018

@Carreau obrigado, vou tentar hoje!

LucianaMarques em 15 out. 2018

@Carreau Estou tendo problemas para usar o @skip_if , nunca usei e não encontrei nenhum documento nele (ou não estou procurando por ele corretamente ...), você tem alguma recomendação de tutoriais / documentos?

LucianaMarques em 15 out. 2018

@LucianaMarques Sempre que começo a programar em uma nova área, procuro encontrar exemplos no código atual. Se você estiver em um sistema baseado em Unix, você pode usar grep para pesquisar a base de código por exemplos de "skip_if" e, por analogia, aplicar ao problema atual.

dsblank em 15 out. 2018

👍1

Acho que não tem sublinhado na base de código IPython.

Por exemplo, lá .

$ rg <strong i="11">@skipif</strong> -tpy
IPython/extensions/tests/test_autoreload.py
133:    @skipif(sys.version_info < (3, 6))

IPython/core/tests/test_interactiveshell.py
531:    @skipif(not hasattr(signal, 'SIGALRM'))

IPython/lib/tests/test_latextools.py
47:<strong i="12">@skipif_not_matplotlib</strong>
62:<strong i="13">@skipif_not_matplotlib</strong>

IPython/lib/tests/test_display.py
182:<strong i="14">@skipif_not_numpy</strong>
 ~/dev/ipython[master ✗] $ rg <strong i="15">@skip_if</strong> -tpy
IPython/lib/tests/test_clipboard.py
7:<strong i="16">@skip_if_no_x11</strong>

IPython/utils/tests/test_path.py
102:<strong i="17">@skip_if_not_win32</strong>
117:<strong i="18">@skip_if_not_win32</strong>
157:<strong i="19">@skip_if_not_win32</strong>
377:    <strong i="20">@skip_if_not_win32</strong>
468:    <strong i="21">@skip_if_not_win32</strong>

... e 10x mais rápido na minha máquina.

Carreau em 15 out. 2018

👍3

Obrigado @Carreau e @dsblank , suas sugestões foram realmente úteis, não acho que estava familiarizado com este comando anteriormente.

Voltarei com uma solicitação de pull em breve.

LucianaMarques em 16 out. 2018

Como prometido, meu pedido de atração .

LucianaMarques em 16 out. 2018

Skip_if for adicionado, vou deixar este aberto para ir à raiz do problema.

Obrigado !

Carreau em 18 out. 2018

Para referência futura e talvez uma correção real em algum momento, isso parece estar acontecendo porque ipython usa uma cláusula SQL "GROUP BY" para esmagar duplicatas, enquanto também seleciona e ordena por colunas que não são colunas de agrupamento nem funções agregadas (sessão e linha). Nem SQL nem sqlite especificam de qual linha de cada grupo resultante os valores para aquelas chamadas colunas "nuas" serão desenhados e, aparentemente, o comportamento real do sqlite mudou em relação a isso.

Tentei algumas variações no SQL gerado, sem sucesso com o sqlite3 3.26.0. Certamente há maneiras de fazer isso, mas há uma questão de tamanho das alterações necessárias e seu efeito no desempenho da pesquisa.