Ipython: Seltsamer Charakter nach dem ersten Import

Hmm, ich habe das hier gesehen, aber mit ^[[43;1R , aber ich nahm an, dass es daran lag, dass ich auf dem Master meines Terminalemulators war. Nicht sicher woher das kommt

Ähnliche Dinge habe ich in den neuesten https://github.com/jonathanslenders/pymux (nicht veröffentlicht, verwendet Prompt-Toolkit 2) gesehen. Vielleicht hat @jonathanslenders eine Idee?

Ich bekomme dasselbe:

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

Wenn ich dann versuche, den Tab abzuschließen:

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

Dies macht die Tab-Vervollständigung fast unbrauchbar.

Ist es möglich, dass dies durch den folgenden Commit behoben wurde: https://github.com/jonathanslenders/python-prompt-toolkit/commit/e226d640177aa1d2cf293e4de382f171586173a2 ?
Es ist in prompt_toolkit master eingebunden, aber ich bin dabei, ein neues prompt_toolkit 2.0 zu veröffentlichen, das es enthält.

Ich habe prompt-toolkit vom Master installiert und das Problem scheint immer noch da zu sein, aber ich bin mir nicht sicher, ob auf der ipython-Seite noch etwas getan werden muss.

Nein, ich bin mir ziemlich sicher, dass dies nicht IPython ist. Ich werde versuchen, mit iterm2 zu reproduzieren

Ich bin mir sicher, dass ich die Komplexität hier nicht verstehe, aber nur zur Information, dies geschieht mit IPython 7.0 und 7.1 und nicht mit 6.0 oder 6.5, die in derselben virtuellen Umgebung getestet werden.

Können Sie alle posten, in welchem ​​Terminal Sie es gesehen haben?
Ich kann auf iTerm2 reproduzieren – 3.2.1beta6 – osx; alacritty v0.2.0-35-ga53cabf osx, aber nicht auf bare macos terminal.app (sierra 10.12.6)

Könnte es sein, dass die beworbenen Funktionen des Terminals nicht übereinstimmen und was sie tatsächlich tun können?

Es ist (für mich) auch nicht reproduzierbar mit ipython --colors=nocolor

Nur nackte Terminal.app auf High Sierra 10.13.6. nocolor repariert es nicht für mich.

Es ist (für mich) auch nicht reproduzierbar mit ipython --colors=nocolor

Kratzen Sie das, es scheint zufällig zu sein, aber in der Tat hat Nocolor es nicht behoben.

Können Sie versuchen, diesen patch_stdout Kontextmanager zu entfernen?

Wenn ich es entferne, scheint es mir in Ordnung zu sein, und wenn ich zusätzlich stdout spüle, bekomme ich das Problem zweimal.

Das Entfernen des Kontextmanagers scheint es für mich zu beheben.

Dies passiert mir entweder in der macOS Terminal.app und in iTerm2. In iTerm2 3.2.1beta tauchte der Charakter jedoch recht durchgängig auf. Heute Morgen habe ich auf 3.2.2beta1 aktualisiert und jetzt scheint der Charakter zu erscheinen und sofort zu verschwinden, ersetzt durch den normalen iPython-Prompt. Aber zumindest in einem Fall war der Charakter hartnäckig, ich bin mir nicht sicher, was der Unterschied war.

Ja, behebt es auch bei mir. Die Wirkung war bei mir immer konstant.

@jonathanslenders könnte es sein, dass Patch stdout eine

Der Parameter raw von patch_stdout scheint auch im ptk-Code nirgendwo hinzugehen.

Es gibt also einen Grund, dies zu haben, oder das Drucken in Hintergrundthreads würde das Rendering durcheinander bringen, aber es sieht (für mich) so aus, als wäre dies eine Wettlaufbedingung zwischen dem Leeren des erfassten stderr/out und dem Wiederherstellen des ursprünglichen Werts.

Ich bin mir nicht sicher, ob Sie den Fehler lokalisiert haben oder noch experimentieren, aber zu Ihrer Information:

• macOS 10.13.6
• iTerm 3.2.1 - zeigt immer ^[[41;1R nach der ersten Eingabe (Import, Ausdruck, sogar Leerzeile)
• Terminal.app 2.8.2 (404) - funktioniert einwandfrei!

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]:

Ich erhalte dies auch (macOS 10.11.6, iTerm 3.2.0beta5) sehr häufig, wenn auch nicht 100% der Zeit, und mit der 43;1R Sequenz.

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]:

Ja, dieser hier bringt mich wirklich um. Ich würde downgraden, aber das macht Jupyter-Notebooks kaputt. Für mich ist die Tabulatorvervollständigung mehr oder weniger komplett gebrochen, da diese Zeichen sehr häufig vorkommen.

Readline ist im Moment leider keine Option: https://github.com/ipython/rlipython/issues/21

Keine Änderung beim Ausführen des aktuellen Masters von prompt_toolkit (Version 2.0.5).

Ich kann es reproduzieren.

iTerm2 build 3.2.3 (ich glaube das neueste), IPython 7.0.1, Python 3.6.1.

Ich hatte den Fehler mit Python 3.6.3 auf Ubuntu und er verschwand mit Python 3.7, obwohl ich einige Störungen sehen kann (wie die Zeichen gedruckt und dann schnell entfernt werden).

Ich habe hier eine Lösung: https://github.com/jonathanslenders/python-prompt-toolkit/commit/09de545476be985b95ae2690ef8393efdd65b7e5

Was Sie in diesem Commit sehen, sind eigentlich zwei einzelne Fixes, die beide das Problem lösen würden (für das, was ich reproduzieren könnte).

• Aus irgendeinem Grund wird ein leerer String erfasst und in stdout geschrieben, kurz bevor die erste Eingabe akzeptiert wird. Dies hat den patch_stdout-Code ausgelöst. Tatsächlich war es nicht nötig, die Eingabeaufforderung zu löschen und erneut zu zeichnen, nur um eine leere Zeichenfolge zu drucken. (Ich muss noch prüfen, warum das tatsächlich passiert.)

• Die eigentliche Lösung besteht darin, auf HLW-Antworten zu warten, bevor der erfasste Inhalt wiedergegeben wird. CPR funktioniert asynchron. Wir fragen nach der Cursorposition, indem wir etwas in stdout schreiben, und wir erhalten die Antwort vom Terminal auf stdin. Es gibt immer eine kleine Verzögerung. Es ist jedoch wichtig, das Terminal im RAW-Modus zu halten und diese Eingabe zu lesen, bis diese Antwort eintrifft. Wir haben das nicht gemacht, und es hat die eigene Antwort des Terminals mit der Cursorposition gerendert.

Das Timing hätte zwischen den Terminals leicht unterschiedlich sein sollen, aber ich denke, dies sollte es tun.

Könnten Sie es alle mit dem neuesten Prompt_toolkit-Commit versuchen? Wenn es funktioniert, werde ich eine neue Version pushen.

Das behebt den Fehler auf meiner Seite. Danke @jonathanslenders !

Ja, vielen Dank, der neueste Master behebt es auch für mich.

Dieser Patch behebt einige [[39;1R Zeichen, die ich auch hatte. Vielen Dank!

EDIT: Kratze das. Ich habe die falsche Version getestet. Ja, das scheint es auch bei mir zu beheben.

Nein, das scheint mir nicht zu helfen. Stattdessen bekomme ich einen anderen Charakter

AlbireoProˇalbireo: Downloads » ipython                 (3.7.0 2.7.15)

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

^[[21;1RIn [2]:

Könnten Sie es alle mit dem neuesten Prompt_toolkit-Commit versuchen? Wenn es funktioniert, werde ich eine neue Version pushen.

funktioniert bei mir. Sie ändern auch die Handhabung von Farben AFAICT, wir haben uns an einigen Stellen in IPython unfreiwillig auf Ansi-Mapping auf Ansi-Code verlassen, das werde ich auch beheben. Vielen Dank !

@Carreau : Ich habe gerade prompt_toolkit 2.0.6 gepusht.
Erwartet IPython, dass bestimmte RRGGBB-Sequenzen bestimmten ANSI-Farben zugeordnet werden, selbst im 256-Farben-Modus?

Übrigens @Carreau , eine Funktion von prompt_toolkit ist jetzt die Möglichkeit, die Helligkeit der Farben zu erhöhen/verringern. Dadurch ist die Anpassung an Terminals mit hellem oder dunklem Hintergrund einfach. Ich habe dies dem Menü von ptpython zum Testen (interaktiv) hinzugefügt und es funktioniert ziemlich gut.

erwarten von

Ich würde nicht "erwarten" sagen, aber die Themen scheinen eine Mischung aus #ansixxx und #00ff00 , die zusammen gut aussahen und mit 2.0.6 in ihren Unterschieden etwas stärker sind.

Ich denke, wir brauchen einfach mehr Konsistenz, ob wir #ansi oder #hex .

Die Helligkeitsoptionen werde ich mir irgendwann anschauen. Ich habe erst vor ein paar Wochen eine neue Stelle angetreten und habe etwas weniger Zeit für die Entwicklung von IPython/Jupyter selbst.

Interessant, aber sinnvoll. Wenn eine Farbe als #00ff00 definiert ist, schaue ich mir die nächste Farbe aus der 256-Farbpalette an, schließe jedoch die 16 Ansi-Farben aus. Das bedeutet, dass es von den verbleibenden 240 Farben am nächsten kommt.

Der Grund dafür ist, dass die Leute heutzutage oft benutzerdefinierte Farbschemata für die ANSI-Farben definiert haben - aber nicht für die 240 verbleibenden Farben. Obwohl es in Ihrer Situation ein wenig abweichen könnte, könnte es für andere Menschen tatsächlich viel näher an der tatsächlichen Farbe sein.

Hier ist ein Beispiel dafür, wie die grundlegenden ANSI-Farben in verschiedenen Terminals gerendert werden:
https://en.wikipedia.org/wiki/ANSI_escape_code#Colors

Schließen wie fest stromaufwärts