Ipython: Caractère étrange après la première importation

Hum, j'ai vu celui-ci mais avec ^[[43;1R , mais j'ai supposé que cela était dû au fait que j'étais maître de mon émulateur de terminal. Je ne sais pas d'où cela vient

J'ai vu des choses similaires dans le dernier https://github.com/jonathanslenders/pymux (non publié, utilise prompt-toolkit 2). Peut-être que @jonathanslenders a une idée ?

j'obtiens le même :

$ ipython
Python 3.6.5 (default, Mar 30 2018, 06:41:53) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.0.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import os                                                                                             

^[[19;1RIn [2]:

Si j'essaie ensuite de terminer la tabulation :

In [2]: os.p                                                                                                  
os.pardir         os.pathconf       os.pathsep        os.popen          os.putenv         
os.path           os.pathconf_names os.pipe           os.pread          os.pwrite         
^[[19;1RIn [2]: os.p

Cela rend la complétion de tabulation presque inutilisable.

Est-il possible que cela ait été corrigé par le commit suivant : https://github.com/jonathanslenders/python-prompt-toolkit/commit/e226d640177aa1d2cf293e4de382f171586173a2 ?
Il est fusionné dans prompt_toolkit master, mais je suis sur le point de publier un nouveau prompt_toolkit 2.0 qui l'inclut.

J'ai installé prompt-toolkit partir de master et le problème semble toujours être là, mais je ne sais pas s'il faut faire autre chose du côté d'ipython.

Non, je suis presque sûr que ce n'est pas IPython. je vais essayer de reproduire avec iterm2

Je suis sûr que je ne comprends pas les complexités ici, mais juste pour information, cela se produit avec IPython 7.0 et 7.1, et ne se produit pas avec 6.0 ou 6.5, en testant dans le même virtualenv.

Pouvez-vous tous poster dans quel terminal vous l'avez vu ?
Je suis capable de reproduire sur iTerm2 – 3.2.1beta6 – osx ; alacritty v0.2.0-35-ga53cabf osx, mais pas sur macos bare terminal.app (sierra 10.12.6)

Serait-ce une inadéquation entre les fonctionnalités annoncées du terminal et ce qu'elles peuvent réellement faire ?

Ce n'est pas non plus reproductible (pour moi) avec ipython --colors=nocolor

Juste à nu Terminal.app sur High Sierra 10.13.6. nocolor ne résout pas le problème pour moi.

Ce n'est pas non plus reproductible (pour moi) avec ipython --colors=nocolor

Grattez ça, ça a l'air d'être aléatoire, mais en effet, nocolor ne l'a pas réparé.

Pouvez-vous essayer de supprimer ce gestionnaire de contexte

Si je le supprime, cela me semble bien, et si je tire une chasse d'eau supplémentaire, j'obtiens le problème deux fois.

La suppression du gestionnaire de contexte semble le résoudre pour moi.

Cela m'arrive dans macOS Terminal.app et dans iTerm2. Cependant, le personnage est apparu assez régulièrement dans iTerm2 3.2.1beta. Ce matin, j'ai mis à niveau vers 3.2.2beta1 et maintenant le personnage semble apparaître et disparaître immédiatement, remplacé par l'invite iPython normale. Mais au moins dans un cas, le personnage a été persistant, je ne sais pas quelle était la différence.

Oui, répare pour moi aussi. L'effet a toujours été cohérent pour moi.

@jonathanslenders se pourrait-il que le patch stdout ait une condition de

Le paramètre raw de patch_stdout ne semble aller nulle part également dans le code ptk.

Il y a donc une raison pour cela, sinon l'impression dans les threads d'arrière-plan perturberait le rendu, mais il me semble qu'il s'agit d'une condition de concurrence entre le vidage de stderr/out capturé et la restauration à leur valeur initiale.

Je ne sais pas si vous avez localisé le bogue ou si vous êtes encore en train d'expérimenter, mais pour votre information :

• macOS 10.13.6
• iTerm 3.2.1 - affiche toujours ^[[41;1R après la première entrée (importation, expression, même ligne vide)
• Terminal.app 2.8.2 (404) - fonctionne très bien !

Python 3.7.0 (default, Sep 18 2018, 18:47:22)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.0.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]:

^[[41;1RIn [1]:

Je reçois également ceci (macOS 10.11.6, iTerm 3.2.0beta5) très fréquemment, mais pas 100% du temps, et avec la séquence 43;1R .

Python 3.7.0 (default, Jun 29 2018, 20:13:53)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.0.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import sqlalchemy

^[[43;1RIn [2]:

Ouais, celui-ci me tue vraiment. Je rétrograderais, mais cela casse les cahiers Jupyter. Pour moi, la complétion de tabulation est plus ou moins complètement cassée, car ces caractères apparaissent très fréquemment.

Malheureusement readline n'est pas une option pour le moment : https://github.com/ipython/rlipython/issues/21

Aucun changement sous le maître actuel de prompt_toolkit (version 2.0.5).

Je peux le reproduire.

iTerm2 build 3.2.3 (je pense que le dernier), IPython 7.0.1, Python 3.6.1.

J'ai eu le bogue avec Python 3.6.3 sur Ubuntu, et il a disparu avec Python 3.7, bien que je puisse voir quelques problèmes (comme les caractères sont imprimés puis rapidement supprimés).

J'ai un correctif ici : https://github.com/jonathanslenders/python-prompt-toolkit/commit/09de545476be985b95ae2690ef8393efdd65b7e5

En fait, ce que vous voyez dans ce commit sont deux correctifs individuels qui résoudraient tous les deux le problème (pour ce que je pourrais reproduire).

• Pour une raison quelconque, une chaîne vide est capturée et écrite sur stdout, juste avant d'accepter la première entrée. Cela a déclenché le code patch_stdout. En fait, il n'était pas nécessaire de faire l'effort d'effacer l'invite et de la dessiner à nouveau, juste pour imprimer une chaîne vide. (Je dois encore vérifier pourquoi cela se produit réellement.)

• La vraie solution consiste à attendre les réponses CPR avant de rendre le contenu capturé. La RCP fonctionne de manière asynchrone. Nous demandons la position du curseur en écrivant quelque chose sur stdout, et nous recevons la réponse du terminal sur stdin. Il y a toujours un peu de retard. Mais il est important de garder le terminal en mode RAW et de lire cette entrée jusqu'à ce que cette réponse arrive. Nous ne l'avons pas fait, et cela a rendu la propre réponse du terminal avec la position du curseur.

Le timing aurait dû être légèrement différent entre les terminaux, mais je suppose que cela devrait le faire.

Pourriez-vous tous essayer avec le dernier commit prompt_toolkit ? Si ça marche, je pousserai une nouvelle version.

Cela corrige le bug de mon côté. Merci @jonathanslenders !

Oui, merci beaucoup, le dernier maître le corrige pour moi aussi.

Ce correctif corrige certains caractères [[39;1R j'avais aussi. Merci!

EDIT : Grattez ça. Je testais la mauvaise version. Oui, cela semble régler le problème pour moi aussi.

Non, cela ne semble pas régler le problème pour moi. Au lieu de cela, j'obtiens un caractère différent

AlbireoProˇalbireo: Downloads » ipython                 (3.7.0 2.7.15)

In [1]: from can.interfaces.slcan import slcanBus

^[[21;1RIn [2]:

Pourriez-vous tous essayer avec le dernier commit prompt_toolkit ? Si ça marche, je pousserai une nouvelle version.

travaille pour moi. Vous modifiez également la gestion des couleurs AFAICT, nous comptions à contrecœur sur le mappage ansi vers le code ansi à certains endroits dans IPython, je vais également corriger cela. Merci !

@Carreau : Je viens de pousser prompt_toolkit 2.0.6.
IPython s'attend-il à ce que certaines séquences RRGGBB correspondent à certaines couleurs ANSI, même en mode 256 couleurs ?

Au fait @Carreau , l'une des fonctionnalités de prompt_toolkit est désormais la possibilité d'augmenter/diminuer la luminosité des couleurs. Cela facilite l'adaptation aux terminaux avec un fond clair ou foncé. J'ai ajouté ceci au menu de ptpython pour les tests (de manière interactive) et cela fonctionne plutôt bien.

attendre

Je ne dirais pas "attendez-vous", mais les thèmes semblent avoir un mélange de #ansixxx et #00ff00 qui allaient bien ensemble, et avec 2.0.6 sont un peu plus forts dans leurs différences.

Je pense que nous avons juste besoin de plus de cohérence quant à savoir si nous utilisons #ansi ou #hex .

Je regarderai les options de luminosité à un moment donné. Je viens de commencer un nouveau poste il y a quelques semaines et j'ai un peu moins de temps pour développer IPython/jupyter lui-même.

Intéressant, mais c'est logique. Lorsqu'une couleur est définie comme #00ff00, je regarde la couleur la plus proche de la palette de 256 couleurs, mais j'exclus les 16 couleurs ansi. Ce qui signifie qu'il prend la plus proche des 240 couleurs restantes.

La raison en est que les gens de nos jours ont souvent des schémas de couleurs personnalisés définis pour les couleurs ANSI - mais pas pour les 240 couleurs restantes. Ainsi, bien que cela puisse être un peu décalé dans votre situation, cela pourrait en fait être beaucoup plus proche de la vraie couleur pour les autres.

Voici un exemple de la façon dont les couleurs ANSI de base sont rendues dans différents terminaux :
https://en.wikipedia.org/wiki/ANSI_escape_code#Colors

fermeture fixe en amont