J'essaie de conditionner ipython 7.0.1 pour openSUSE et j'obtiens l'erreur suivante dans les tests unitaires:
======================================================================
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\')]')
----------------------------------------------------------------------
Il semble que les deux derniers éléments de la liste ont changé de place, mais je ne sais pas pourquoi cela pourrait être le cas.
ÉDITER:
Nous pouvons probablement résoudre ce problème en deux étapes:
1) marquez le test comme ignoré (ou échec connu) pour la plage de versions de sqlite qui semblent être affectées.
2) Déterminez en fait s'il s'agit d'un changement de comportement qui mérite d'être corrigé ou si le test doit être mis à jour en conséquence.
toddrme2178
Tous les 16 commentaires
Sur quelle version de Python utilisez-vous cela? Regardez également la version de sqlite.
Carreau
le 10 oct. 2018
Voici les versions python et sqlite:
libsqlite3-0-3.25.0-1.1
python3-3.6.5-3.4
Et un autre, je suppose, pourrait être pertinent:
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
Le problème semble également se produire dans la version 6.5. Il semble que le problème est survenu pour la première fois lorsque nous sommes passés de sqlite3 3.24.0 à 3.25.0.
toddrme2178
le 13 oct. 2018
en fait pour z=5 le deuxième nombre du tuple a changé. c'est le line number (AFAICT).
Alors pourquoi 4 au lieu de 1 ...? Il se peut que lorsque nous demandons unique nous demandons uniquement l'uniq dans la 3ème colonne et sqlite est heureux de changer son comportement interne et de l'uniquifier avant le tri, renvoyant ainsi la deuxième itération de z=5 ?
Carreau
le 14 oct. 2018
J'ai manqué ça. Mais je ne sais vraiment rien sur SQL, donc je ne sais pas pourquoi cela pourrait se produire. J'ai confirmé que le problème persiste avec sqlite 3.25.2, la dernière version.
toddrme2178
le 14 oct. 2018
Je ne suis pas non plus un expert SQL, d'après ce que je peux dire, l'échec du test n'est pas
critique. Un marqueur "d'échec connu" vous aiderait-il à créer un package pour openSUSE ou
préférez-vous en trouver la cause?
Le dimanche 14 octobre 2018, 12:28 Todd [email protected] a écrit:
J'ai manqué ça. Mais je ne sais vraiment rien de SQL donc je ne sais pas
pourquoi cela pourrait arriver. J'ai confirmé que le problème persiste avec
sqlite 3.25.2, la dernière version.-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/ipython/ipython/issues/11372#issuecomment-429654816 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAUez9oGI6J02rTiDIfuzUCrpY71axO9ks5uk5B1gaJpZM4XMOVJ
.
Carreau
le 14 oct. 2018
Je ne sais pas à quel point le bogue est grave, je m'en remets donc à votre jugement. Bien sûr, une vraie solution est préférable, mais si vous pensez que le problème est suffisamment mineur, nous pouvons aller avec un échec connu pour le moment.
toddrme2178
le 14 oct. 2018
@LucianaMarques vous cherchiez quelque chose de facile, cela ne devrait pas être trop difficile d'ajouter un "@skip_if" avec une condition comme ... sqlite3.sqlite_version_info > (x, y, z)
Nous pouvons reporter cela à plus tard.
Carreau
le 15 oct. 2018
@Carreau merci, je vais essayer aujourd'hui!
LucianaMarques
le 15 oct. 2018
@Carreau J'ai du mal à utiliser @skip_if , je ne l'ai jamais utilisé et je n'ai trouvé aucune documentation dessus (ou je ne la recherche pas correctement ...), avez-vous des recommandations de tutoriels / documents?
LucianaMarques
le 15 oct. 2018
@LucianaMarques Chaque fois que je commence à coder dans une nouvelle zone, j'essaye de trouver des exemples dans le code actuel. Si vous êtes sur un système Unix, vous pouvez utiliser grep pour rechercher dans la base de code des exemples de "skip_if" et, par analogie, appliquer au problème actuel.
dsblank
le 15 oct. 2018
Je pense que c'est sans soulignement sur la base de code IPython.
Par exemple là-bas .
@dsblank avez-vous essayé RipGrep ? Vraiment bien: ignorez .git par défaut, recherchez récursivement par défaut, mettez en surbrillance la couleur et filtrez par types de fichiers. Exemple de recherche pour skipif uniquement dans les fichiers 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>
... et 10 fois plus rapide sur ma machine.
Carreau
le 15 oct. 2018
Merci @Carreau et @dsblank , vos suggestions ont été vraiment utiles, je ne pense pas que je connaissais auparavant cette commande.
Je reviendrai bientôt avec une pull request.
LucianaMarques
le 16 oct. 2018
Comme promis, ma pull request .
LucianaMarques
le 16 oct. 2018
Skip_if a été ajouté, je vais laisser celui-ci ouvert pour aller à la racine du problème.
Merci !
Carreau
le 18 oct. 2018
Pour référence future et peut-être un vrai correctif parfois, cela semble se produire car ipython utilise une clause SQL "GROUP BY" pour écraser les doublons, tout en sélectionnant et en triant par colonnes qui ne sont ni des colonnes de regroupement ni des fonctions d'agrégation (session et ligne). Ni SQL ni sqlite ne spécifient à partir de quelle ligne de chaque groupe résultant les valeurs de ces colonnes dites "nues" seront tirées, et apparemment le comportement réel de sqlite a changé à cet égard.
J'ai essayé quelques variations sur le SQL généré, sans succès contre sqlite3 3.26.0. Il existe certainement des moyens de le faire, mais il y a une question de l'ampleur des modifications requises et de leur effet sur les performances de recherche.
jcbollinger
le 20 avr. 2020
Questions connexes
alvations
·
4Commentaires
jakirkham
·
4Commentaires
sataliulan
·
4Commentaires
zhao-ji
·
4Commentaires
gregcaporaso
·
3Commentaires
Commentaire le plus utile
Je pense que c'est sans soulignement sur la base de code IPython.
Par exemple là-bas .
@dsblank avez-vous essayé RipGrep ? Vraiment bien: ignorez .git par défaut, recherchez récursivement par défaut, mettez en surbrillance la couleur et filtrez par types de fichiers. Exemple de recherche pour skipif uniquement dans les fichiers python:
... et 10 fois plus rapide sur ma machine.