Ipython: ошибка test_history

Созданный на 8 окт. 2018 · 16Комментарии · Источник: ipython/ipython

Я пытаюсь упаковать ipython 7.0.1 для openSUSE и получаю следующую ошибку в модульных тестах:

======================================================================
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\')]')


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

Похоже, что последние два элемента списка поменялись местами, но я не знаю, почему это может быть так.

РЕДАКТИРОВАТЬ:

Скорее всего, мы сможем решить эту проблему в два этапа:

1) пометьте тест как пропущенный (или заведомо неудачный) для диапазона версий sqlite, которые, по-видимому, затронуты.
2) выяснить, стоит ли исправить это изменение в поведении или нужно соответствующим образом обновить тест.

Hacktoberfest help wanted

Источник

toddrme2178

Самый полезный комментарий

Я думаю, это без подчеркивания в кодовой базе IPython.

Например там .

@dsblank вы пробовали RipGrep ? Действительно хорошо: по умолчанию пропускать .git, по умолчанию рекурсивный поиск, выделение цветом и фильтрация по типам файлов. Пример поиска skipif только в файлах 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>

... и в 10 раз быстрее на моей машине.

Carreau 15 окт. 2018

👍3

Все 16 Комментарий

На какой версии Python вы это используете? Посмотрите также версию sqlite.

Carreau 10 окт. 2018

Вот версии python и sqlite:

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

И некоторые другие, я думаю, могут иметь отношение:

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 10 окт. 2018

Проблема также возникает в версии 6.5. Похоже, проблема впервые возникла, когда мы перешли с sqlite3 3.24.0 на 3.25.0.

toddrme2178 13 окт. 2018

фактически для z=5 изменилось второе число в кортеже. это line number (AFAICT).

Так почему 4 вместо 1 ...? Может случиться так, что когда мы запрашиваем unique мы запрашиваем uniq только по 3-му столбцу, и sqlite рад изменить его внутреннее поведение и унифицировать перед сортировкой, возвращая таким образом вторую итерацию z=5 ?

Carreau 14 окт. 2018

Я пропустил это. Но я действительно ничего не знаю о SQL, поэтому не знаю, почему это может происходить. Я подтвердил, что проблема все еще возникает с последней версией sqlite 3.25.2.

toddrme2178 14 окт. 2018

Я тоже не специалист по SQL, судя по тому, что провал теста не
критический. Поможет ли вам маркер «известного сбоя» упаковать для openSUSE или
вы предпочитаете найти первопричину?

В вс, 14 октября 2018 г., 12:28 Тодд [email protected] написал:

Я пропустил это. Но я действительно ничего не знаю о SQL, поэтому я не знаю
почему это может происходить. Я подтвердил, что проблема все еще возникает с
sqlite 3.25.2, последняя версия.
-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/ipython/ipython/issues/11372#issuecomment-429654816 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAUez9oGI6J02rTiDIfuzUCrpY71axO9ks5uk5B1gaJpZM4XMOVJ
.

Carreau 14 окт. 2018

Я не знаю, насколько серьезна ошибка, поэтому я полагаюсь на ваше мнение. Конечно, реальное исправление предпочтительнее, но если вы считаете, что проблема достаточно незначительна, мы можем пока отказаться от известного сбоя.

toddrme2178 14 окт. 2018

@LucianaMarques, вы искали что-то легкое, что не должно быть слишком сложно добавить "@skip_if" с условием вроде ... sqlite3.sqlite_version_info > (x, y, z)

Мы можем отложить исправление этого на потом.

Carreau 15 окт. 2018

@Carreau, спасибо, я попробую сегодня!

LucianaMarques 15 окт. 2018

@Carreau У меня проблемы с использованием @skip_if , я никогда не использовал его и не нашел по нему документов (или я не ищу его должным образом ...), у вас есть какие-либо рекомендации по учебникам / документам?

LucianaMarques 15 окт. 2018

@LucianaMarques Всякий раз, когда я начинаю кодировать в новой области, я пытаюсь найти примеры в текущем коде. Если вы работаете в системе на основе Unix, вы можете использовать grep для поиска в кодовой базе примеров «skip_if» и, по аналогии, применить к текущей проблеме.

dsblank 15 окт. 2018

👍1

Я думаю, это без подчеркивания в кодовой базе IPython.

Например там .

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

... и в 10 раз быстрее на моей машине.

Carreau 15 окт. 2018

👍3

Спасибо @Carreau и @dsblank , ваши предложения были действительно полезными, я не думаю, что раньше был знаком с этой командой.

Я скоро вернусь с запросом на перенос.

LucianaMarques 16 окт. 2018

Как и было обещано, мой запрос на перенос .

LucianaMarques 16 окт. 2018

Skip_if был добавлен, я оставлю это открытым, чтобы перейти к корню проблемы.

Спасибо !

Carreau 18 окт. 2018

Для справки в будущем и, возможно, когда-нибудь для реального исправления, это, похоже, происходит потому, что ipython использует предложение SQL «GROUP BY» для сжатия дубликатов, а также выбирает и упорядочивает столбцы, которые не являются ни группирующими столбцами, ни агрегатными функциями (сеанс и строка). Ни SQL, ни sqlite не указывают, из какой строки каждой результирующей группы будут извлечены значения для этих так называемых «голых» столбцов, и, очевидно, фактическое поведение sqlite изменилось в этом отношении.

Я попробовал несколько вариантов сгенерированного SQL, но безуспешно против sqlite3 3.26.0. Конечно, есть способы сделать это, но вопрос в размере требуемых изменений и их влиянии на производительность поиска.