Ipython: test_history failure

Dibuat pada 8 Okt 2018  ·  16Komentar  ·  Sumber: ipython/ipython

Saya mencoba mengemas ipython 7.0.1 untuk openSUSE dan saya mendapatkan kesalahan berikut dalam pengujian unit:

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


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

Sepertinya dua elemen daftar terakhir telah bertukar tempat tetapi saya tidak tahu mengapa itu mungkin terjadi.


EDIT:

Kami mungkin dapat memperbaiki masalah ini dalam dua langkah:

1) tandai pengujian sebagai lewati (atau diketahui gagal) untuk rentang versi sqlite yang tampaknya terpengaruh.
2) benar-benar mencari tahu apakah ini adalah perubahan dalam perilaku yang layak diperbaiki atau jika tes harus diperbarui sebagaimana mestinya.

Hacktoberfest help wanted

Komentar yang paling membantu

Saya pikir itu tanpa garis bawah pada basis kode IPython.

Misalnya di sana .

@dsblank sudah coba RipGrep ? Benar-benar bagus: lewati .git secara default, telusuri secara rekursif secara default, sorot warna, dan filter menurut jenis file. Contoh fr mencari skipif hanya di file 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>

... dan 10x lebih cepat di komputer saya.

Semua 16 komentar

Versi Python mana yang Anda gunakan? Lihat juga versi sqlite.

Berikut adalah versi python dan sqlite:

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

Dan beberapa lainnya yang saya rasa mungkin relevan:

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

Masalahnya juga tampaknya terjadi di versi 6.5. Sepertinya masalah pertama kali terjadi saat kami beralih dari sqlite3 3.24.0 ke 3.25.0.

sebenarnya untuk z=5 angka kedua di tupel telah berubah. itu adalah line number (AFAICT).

Jadi mengapa 4 bukannya 1 ...? Mungkin ketika kita meminta unique kita hanya meminta uniq wrt kolom ke-3 dan sqlite dengan senang hati mengubah perilaku internalnya dan unik sebelum menyortir, sehingga mengembalikan iterasi kedua dari z=5 ?

Saya melewatkan itu. Tetapi saya tidak benar-benar tahu apa-apa tentang SQL jadi saya tidak tahu mengapa hal itu bisa terjadi. Saya telah mengkonfirmasi masalah masih terjadi dengan sqlite 3.25.2, versi terbaru.

Saya juga bukan ahli SQL, dari apa yang saya tahu bahwa pengujian gagal
kritis. Apakah penanda "gagal yang diketahui" membantu Anda membuat paket untuk openSUSE atau
apakah Anda lebih suka menemukan akar masalahnya?

On Sun, 14 Okt 2018, 12:28 Todd [email protected] menulis:

Saya melewatkan itu. Tapi saya tidak benar-benar tahu apa-apa tentang SQL jadi saya tidak tahu
mengapa itu mungkin terjadi. Saya telah mengonfirmasi bahwa masalah masih terjadi dengan
sqlite 3.25.2, versi terbaru.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/ipython/ipython/issues/11372#issuecomment-429654816 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAUez9oGI6J02rTiDIfuzUCrpY71axO9ks5uk5B1gaJpZM4XMOVJ
.

Saya tidak tahu seberapa serius bugnya, jadi saya akan tunduk pada penilaian Anda. Tentu saja perbaikan yang sebenarnya lebih disukai, tetapi jika menurut Anda masalahnya cukup kecil, kita dapat melanjutkan dengan kegagalan yang diketahui untuk saat ini.

@LucianaMarques Anda mencari sesuatu yang mudah, yang seharusnya tidak terlalu sulit untuk menambahkan "@skip_if" dengan ketentuan seperti ... sqlite3.sqlite_version_info > (x, y, z)

Kami dapat menunda memperbaikinya nanti.

@Carreau terima kasih, saya akan mencobanya hari ini!

@Carreau Saya mengalami kesulitan untuk menggunakan @skip_if , saya belum pernah menggunakannya dan tidak menemukan dokumen di dalamnya (atau saya tidak mencarinya dengan benar ...), apakah Anda memiliki rekomendasi tutorial / dokumen?

@LucianaMarques Setiap kali saya mulai membuat kode di area baru, saya mencoba mencari contoh dalam kode saat ini. Jika Anda menggunakan sistem berbasis Unix, Anda dapat menggunakan grep untuk mencari basis kode untuk contoh "skip_if" dan, dengan analogi, berlaku untuk masalah saat ini.

Saya pikir itu tanpa garis bawah pada basis kode IPython.

Misalnya di sana .

@dsblank sudah coba RipGrep ? Benar-benar bagus: lewati .git secara default, telusuri secara rekursif secara default, sorot warna, dan filter menurut jenis file. Contoh fr mencari skipif hanya di file 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>

... dan 10x lebih cepat di komputer saya.

Terima kasih @Carreau dan @dsblank , saran Anda sangat membantu, saya rasa saya sebelumnya tidak terbiasa dengan perintah ini.

Saya akan segera kembali dengan permintaan tarik.

Seperti yang dijanjikan, permintaan tarik saya.

Skip_if telah ditambahkan, saya akan membiarkan yang ini terbuka untuk menuju ke akar masalah.

Terima kasih!

Untuk referensi di masa mendatang dan mungkin suatu saat perbaikan nyata, hal ini tampaknya terjadi karena ipython menggunakan klausa SQL "GROUP BY" untuk menghilangkan duplikat, sementara juga memilih dan mengurutkan berdasarkan kolom yang bukan merupakan kolom pengelompokan atau fungsi agregat (sesi dan baris). Baik SQL maupun sqlite tidak menentukan dari baris mana dari setiap grup yang dihasilkan, nilai untuk apa yang disebut kolom "telanjang" akan ditarik, dan tampaknya perilaku sebenarnya sqlite berubah dalam hal itu.

Saya mencoba beberapa variasi pada SQL yang dihasilkan, namun tidak berhasil melawan sqlite3 3.26.0. Memang ada cara untuk melakukannya, tetapi ada pertanyaan tentang ukuran perubahan yang diperlukan dan pengaruhnya terhadap kinerja pencarian.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat