Ipython: Readline-Fähigkeit zurückholen?

Ich bin bereit, die Arbeit zu tun, um dies rechtzeitig für 6.0 zurückzubekommen, also werde ich #10329 hier markieren.

Ich denke, dies ist ein besonders wichtiges Thema, da langjährige Benutzer und Befürworter von IPython frustriert sind oder sogar nicht bereit sind, IPython 5 so zu verwenden, wie es jetzt ist.

Ich füge das gerne wieder als Option hinzu, obwohl der größte Teil des Codes entfernt wurde und dies wahrscheinlich ein großer Aufwand sein wird, um readline wieder zu integrieren.

Wenn wir herausfinden können, wie wir das optional machen können (so dass es sich schneller als der Kern entwickeln kann, um potenzielle Fehler, die durch das Revival eingeführt wurden, erneut zu beheben, wäre das großartig.

Vielleicht möchten wir #10356 verzögern, wenn wir RL zurückbringen.

Siehe auch #9260.

Und #9399 ist der Großteil der Entfernung.

Ich bin diesbezüglich stark -1. Wir konnten viel Code und Komplexität reduzieren, als wir readline aufgegeben haben (und wir arbeiten daran, noch mehr zu reduzieren), während die Benutzererfahrung für die meisten Benutzer dramatisch verbessert wurde. Wenn wir eine readline-Option zurückbringen, müssen wir die gesamte Komplexität beider Schnittstellen ~für immer beibehalten. Wir wussten immer, dass eine so große Änderung einige Arbeitsabläufe beeinträchtigen würde, aber ich bin zuversichtlich, dass es sich um eine Nettoverbesserung handelt, und ich möchte nicht, dass wir zwei alternative Terminalschnittstellen pflegen.

Ich hätte lieber wir:

1. Arbeiten Sie weiter an allem, was wir sowohl in IPython als auch in prompt_toolkit verbessern können, um Hindernisse für den Wechsel zu beseitigen. Jonathan war im Allgemeinen beeindruckend reaktionsschnell und hilfsbereit, wenn wir ihn zu Problemen im Zusammenhang mit PTK anpingten, daher denke ich, dass wir gute Chancen haben, alle erforderlichen Änderungen akzeptiert zu bekommen. Dazu gehören Dinge wie eine bessere Dokumentation, wie benutzerdefinierte Tastenkombinationen festgelegt werden, und vielleicht das Experimentieren mit dem Lesen von .inputrc (obwohl ich es vorziehen würde, dass dies aus Gründen, die ich an anderer Stelle erklärt habe, standardmäßig deaktiviert ist). Wenn wir den Leuten eine einfache Möglichkeit geben, zu readline zurückzukehren, werden diese Verbesserungen nicht passieren.
2. Wenn es immer noch Leute gibt, die wirklich darauf bestehen, readline zu benutzen, spinnen Sie ein separates Paket wie rlipython , das die Terminal-Schnittstelle bereitstellt, aber machen Sie deutlich, dass es von der Community gepflegt wird und nicht etwas, das wir offiziell unterstützen.

Angesichts der Tatsache, dass es unter Windows immer eine Reihe von Problemen mit pyreadline gab (nicht zuletzt die Tatsache, dass es sowohl die standardmäßige Python-REPL als auch IPython betrifft), würde ich es vorziehen, dass (py)readline nicht als Standard verwendet wird zumindest unter Windows. Wenn ein Benutzer es vorzieht, pyreadline manuell zu installieren und zu aktivieren, ist das in Ordnung, aber IPython sollte ohne pyreadline funktionieren und es nicht als Abhängigkeit einer normalen Installation einschließen.

Wenn es immer noch Leute gibt, die wirklich darauf bestehen, readline zu benutzen, spinnen Sie ein separates Paket wie rlipython heraus, das die Terminal-Schnittstelle bereitstellt, aber machen Sie deutlich, dass es von der Community gepflegt wird und nicht etwas, das wir offiziell unterstützen.

Ich denke, das ist vernünftig, obwohl ich glaube, dass eine Integration (wie ein Flag und / oder eine env-Variable) mit IPython vernünftig ist, um das vorherige Verhalten wiederherzustellen. Das Ziel wäre es, bereits gut verbreitete Skripte und Rezepte zu haben, die auf IPython readline basieren und noch mit einem einfachen Switch funktionieren.

Ich vermute, dass eine einfache Konfiguration in IPythonApp ausreichen würde, mit der die TerminalInteractiveShell-Klasse ein Traitlet verwendet, sowie ein --readline-Flag, das einen voreingestellten Wert für ein bekanntes externes Paket hat.

Das ipython als separates Paket ermöglicht es auch, IPython 6 nicht zu blockieren und bei Bedarf einen schnellen Iterationszyklus zu erhalten.

Wenn wir den Leuten eine einfache Möglichkeit geben, zu readline zurückzukehren, werden diese Verbesserungen nicht passieren.

Ich bezweifle, dass das ganz richtig ist. Die Multiline, Hervorhebung und nun Vervollständigung sind nach wie vor ein großer Vorteil der PTK-Schnittstelle. Und Benutzer, die an 4.x anheften, weil sie nicht einmal RL/PTK parallel verwenden können, haben keinen Anreiz, Patch an IPython / PTK zu senden, um das Verhalten zu glätten.

Ich würde es nicht in einen Switch integrieren, weil es dann wie eine unterstützte Option aussieht und die Leute hier Fehler darüber melden. rlipython ist sowieso weniger Tipparbeit als ipython --readline , und wenn die Leute es gerne als ipython verwenden möchten, können sie es mit einem Pseudonym verwenden.

Nur eine Anmerkung zur aktuellen Erfahrung von ctrl-r :

Wenn Sie in Bash Strg-R und dann Escape drücken, werden Sie ausgeschieden.

In diesem tut es nichts, wenn es den Suchbereich schließen soll.

Nur eine Anmerkung zur aktuellen Erfahrung mit ctrl-r:
Wenn Sie in Bash Strg-R und dann Escape drücken, werden Sie ausgeschieden.
In diesem tut es nichts, wenn es den Suchbereich schließen soll.

Dieser ist leicht zu beheben, aber nicht vollständig:

 ~/dev/ipython master [1]"!!" $ git diff
diff --git a/IPython/terminal/shortcuts.py b/IPython/terminal/shortcuts.py
index 22ad111..89713cd 100644
--- a/IPython/terminal/shortcuts.py
+++ b/IPython/terminal/shortcuts.py
@@ -54,6 +54,10 @@ def register_ipython_shortcuts(registry, shell):
     registry.add_binding(Keys.ControlC, filter=HasFocus(DEFAULT_BUFFER)
                         )(reset_buffer)

+
+    registry.add_binding(Keys.Escape, filter=HasFocus(SEARCH_BUFFER)
+                        )(reset_search_buffer)
+
     registry.add_binding(Keys.ControlC, filter=HasFocus(SEARCH_BUFFER)
                         )(reset_search_buffer)

Das wird funktionieren, aber I-search-backward: wird immer noch sichtbar sein, bis Sie eine neue Taste drücken. Dieser neue Schlüssel wird sich verhalten, wenn die Rückwärtssuche verworfen wurde, aber es fühlt sich extrem seltsam an.

Danke fürs Öffnen, @ivanov! Ich werde die Details etwas genauer durchgehen, ich werde auch zu mehr Feedback zu der Liste dazu ermutigen. Es ist offensichtlich eine schwierige Balance und umstritten, also ein gutes Zeichen dafür, dass mehr Stimmen zumindest unseren Entscheidungsprozess beeinflussen können.

Nur ein Update zum möglichen Weg nach vorne für diese Bemühungen: Anstatt den entfernten Code in IPython zu bringen, hat @Carreau ein neues Projekt mit nur dem alten readline-basierten Code bei Carreau/rlipython erstellt und #10373 erstellt, das es Benutzern ermöglicht, passen Sie dieses Stück an.

Zu Ihrer Information: das Problem, das in der Mailingliste beschrieben ist:

Ich frage hauptsächlich, weil in SMC zumindest, wenn Sie versuchen, mehrere einzufügen
Zeilen, die es in die erste Zeile einfügt und alles stillschweigend

(dh term.js). Allerdings ist es ziemlich frustrierend.

Dies weist darauf hin, dass dieses Terminal kein Einfügen in Klammern unterstützt.
IMHO: Ich denke, dass wir heutzutage von jedem Terminal erwarten können, dass es dies unterstützt: https://cirw.in/blog/bracketed-paste (Zumindest erfordert prompt_toolkit Klammern einfügen, um mehrzeiligen Text einzufügen.)

Es könnte sich lohnen, die Readline-Unterstützung erneut hinzuzufügen, aber beachten Sie, dass mehrere der genannten Fehler bereits behoben sind oder behoben werden. Die größten Probleme sind wahrscheinlich das Emacs-Terminal (das nicht wirklich ein xterm-kompatibles Terminal ist und nie unterstützt wird) und die .inputrc-Unterstützung, die irgendwann kommen wird, aber aufgrund von Bandbreiten- / Prioritätsproblemen auf meiner Seite einige Zeit in Anspruch nehmen wird.

Melden Sie in jedem Fall weiterhin Probleme mit der Benutzererfahrung. Das ist wichtig.

@pfmoore das ist ein guter Punkt. Ich würde bezweifeln, dass Windows-Umgebungen durch das Fehlen von Pyrreadline schaden. Wenn wir die Readline-Benutzeroberfläche zurückbringen, ist es wahrscheinlich sinnvoll, dies nur für "echte" Readline zu tun, sei es in IPython oder im rlipython Paket.

Ein Vorteil des separaten rlipython-Pakets besteht darin, dass es mit dem bestehenden IPython 5-Release verwendet werden kann, während dies in IPython selbst offensichtlich nur für neue IPython-Releases funktioniert.

Ich möchte #9799 als eine weitere Quelle des Unbehagens mit den prompt_toolkit-Standardeinstellungen hinzufügen. Ich wäre vollkommen zufrieden mit einem zusätzlichen externen Paket zu installieren.

pyreadline ist unter Windows mühsam, aber prompt-toolkit hat auch Probleme. Zwischen 2 unbefriedigenden Lösungen sieht die Lösung mit weniger "technischen Schulden" wie die beste Lösung aus: Prompt-Toolkit.

Ich denke, der Punkt ist, dass prompt_toolkit für einige Leute besser ist und readline für andere besser ist. Die Frage ist also, ist es notwendig, die Readline-Leute loszulassen, um zu vermeiden, dass der zusätzliche Code beibehalten wird?

pyreadline ist unter Windows mühsam, aber prompt-toolkit hat auch Probleme. Zwischen 2 unbefriedigenden Lösungen sieht die Lösung mit weniger "technischen Schulden" wie die beste Lösung aus: Prompt-Toolkit.

Ich denke, der Punkt ist, dass prompt_toolkit für einige Leute besser ist und readline für andere besser ist. Die Frage ist also, ist es notwendig, die Readline-Leute loszulassen, um zu vermeiden, dass der zusätzliche Code beibehalten wird?

Beachten Sie, dass die angehängte PR (#10373) im Moment 4 Zeilen umfasst und nur eine Konfigurationsoption ist, um sie zu einer Konfigurationsoption zu machen. Der Readline-Code wäre nicht einmal in IPython und wäre eine Erweiterung.

Die eigentliche Frage ist:

• A: Ist es in Ordnung, wenn readline-ipython eine separate ausführbare Datei mit einer anderen Schreibweise ist.
• B: Oder für Skripte und Erweiterungen, die nach IPython ausgeben (z. B. Emacs), sollte es eine IPython-Konfigurationsoption sein.

In beiden Fällen wird readline nicht wieder von IPython abhängig gemacht.

Es beeinflusst einige Funktionen, die in IPython einfacher zu halten sind, aber der Hauptstreitpunkt ist derzeit A oder B.

Von der Emacs-Seite ist beides in Ordnung. B scheint auf Dauer flexibler zu sein.

Ich denke, für diejenigen von uns, die Readline bevorzugen, möchten wir, dass Readline auch für IPython ausgegeben wird - also B.

Ich habe eine Weile darüber nachgedacht und mit ein paar Leuten im Team gesprochen, mit denen ich mich persönlich engagieren konnte. Hier ist meine Meinung zu der Sache. Ich bin noch keine endgültige Entscheidung anrufen, aber ich versuche , uns näher an eine Auflösung zu bewegen. Übrigens, ich möchte betonen, dass ich dem Prompt Toolkit-Team sehr dankbar bin, da es uns in den allermeisten Fällen eine erstaunliche, moderne und qualitativ hochwertige Benutzererfahrung bietet. Zur Sache:

• Die Bedenken der Benutzer, die Readline benötigen, sind sehr real, und ich denke, wir sollten jetzt eine gute Lösung für sie finden, auch wenn die Kosten etwas zusätzlichen Code in/um IPython mit sich bringen.

• Wir werden weiterhin mit dem PT-Team zusammenarbeiten, um es in Richtung auf Funktionsparität mit Readline zu verbessern, wo dies ein Problem darstellt (ich bin mir bewusst, dass es eine riesige Sammlung von Funktionen hat, die RL nicht hat).

• Selbst wenn sich PT weiter verbessert, kann ich immer noch Situationen sehen, in denen einfache alte Readline wertvoll sein werden. PT ist aufgrund seiner Raffinesse wahrscheinlich langsamer oder spröder, wenn es beispielsweise innerhalb von tmux über ssh innerhalb einer ipython-Shell innerhalb von Emacs läuft. Das ist ein gültiger Anwendungsfall, den wir gut unterstützen sollten, und den wir früher gemacht haben.

Vor diesem Hintergrund denke ich, dass eine gute Kompromisslösung in etwa dem entspricht, was

• wir unterstützen readline, aber nur über ein Drittanbieterpaket, das vom Benutzer manuell installiert werden muss.

• Der Benutzer kann dann entweder die Verwendung dieses Pakets in seiner Konfigurationsdatei festlegen, es über die Befehlszeile aufrufen oder einen Shell-Alias ​​oder ein winziges Wrapper-Skript schreiben. Ja, dies erfordert von den Benutzern dieses Eckgehäuses ein wenig zusätzliche Arbeit, aber es gibt ihnen eine saubere Lösung zu minimalen Kosten, während die Mehrheit der Benutzer, die PT verwenden (und von seinen Funktionen profitieren), dies ohne Unterbrechung tun .

Dies bedeutet, dass dieses zusätzliche Paket für eine Weile unterstützt wird, aber ich kann mir nicht vorstellen, dass es so viel Arbeit sein wird: Dieser Code hat sich seit einiger Zeit kaum geändert, und wir sprechen nicht darüber, viele neue Funktionen hinzuzufügen. Einfach die Kompatibilität mit vorhandenem, historischem Basislinienverhalten aufrechterhalten.

Die Kosten, die ich als etwas erheblich ansehe, sind die (von @Carreau erwähnten) Codes, die wir herausreißen möchten, die uns daran hindern würden, sie zu entfernen. Ich sehe das als einen Preis, den wir zum Wohle unserer Nutzer zahlen sollten, zumindest vorerst. Wenn wir uns irgendwann in der Zukunft wirklich in einer Situation befinden, in der PT in jedem erdenklichen Fall ein 100-prozentiger Ersatz für RL ist, können wir es erneut versuchen. Aber im Moment ist es das Richtige, ein bisschen veralteten, speziellen Code zum Nutzen einiger unserer Benutzer zu behalten. Im Laufe der Jahre hatten wir mehrere Arten von Code für Sonderfälle (Windows, py2/3 usw.) und ich bin sicher, dass wir das in Zukunft wieder tun werden. Die Bedienung der Workflows unserer Benutzer sollte meiner Meinung nach Vorrang vor einer Codebereinigung haben (in dieser Situation keine pauschale Aussage).

Wie klingt das?

Übrigens, ich denke, dieser "Fix" sollte auf die 5.x-Serie zurückportiert werden: Wenn überhaupt, vermute ich, dass die Population der Benutzer, die noch Python 2.x verwenden, eine gute Überschneidung mit der von Leuten hat, die remote auf älteren Servern arbeiten. Meine Stimme wäre also, das externe Paket mit Python 2-3 kompatibel zu machen und die Ipython-Seite des Codes auf 5.x zurückzuportieren.

Danke Fernando, dass du dir die Zeit genommen hast zu antworten und vor allem, dass du mehrere Leute erreicht hast.
Ich werde daran arbeiten, meine PR zu polieren, zusammenzuführen und auf 5.0 zurück zu portieren.

Ich habe rlipython auf GitHub für alle, die daran interessiert sind, die Readline-Schnittstelle zu pflegen. Ich werde es nicht pflegen und nicht auf PyPI veröffentlichen, aber Sie können es gerne tun, und es könnte eine gute Sache sein, dies nach https://github.com/ipython-contrib zu verschieben, wenn Sie eine Organisation benötigen .

Vielen Dank !

Ich denke eigentlich, wir sollten dies auf der Haupt-IPython-Organisation hosten und auf pypi stellen. Wir können der Community auch eine etwas einladendere Nachricht senden, wie folgt:

Dies ist etwas, das wir zur Unterstützung der historischen Kompatibilität und bestimmter spezifischer Anwendungsfälle anbieten, in denen unsere Hauptschnittstelle (Prompt-Toolkit) nicht optimal ist. Aber wir sehen keine bedeutende Entwicklung über die Behebung kritischer Fehler hinaus. Wir haben nur die Ressourcen, um dies als Best-Effort-Lösung anzubieten. Wenn Sie an einer wesentlichen Entwicklung dieses Tools interessiert sind, teilen Sie uns dies bitte über ein Problem mit, und wir können prüfen, ob Sie die Wartung des Pakets an Sie übertragen."

Wenn @ivanov ein paar Zyklen in diese Richtung hätte, wäre das großartig, aber wenn nicht, bin ich bereit, dies in den nächsten Wochen zu tun. Ich denke, es ist ein wichtiger Teil der Interaktion mit allen Ecken unserer Benutzergemeinschaft.

Danke @Carreau, dass vorangetrieben hast !

Vielen Dank an alle, insbesondere @Carreau, dass Sie rlipython hochgebracht haben. Ich habe angefangen, daran zu arbeiten und es in Form zu bringen. Falls es jemand verpasst hat, es lebt jetzt unter ipython/rlipython . Ich werde versuchen, in den nächsten zwei Wochen eine Veröffentlichung herauszubringen, wenn ich damit beginne, aber im Moment kann ich sagen, dass es funktioniert! Es gibt derzeit ein bekanntes Problem - Eingabeaufforderungen für Ein-/Ausgänge werden nicht gefärbt, was ich in ipython / rlipython # 3 verfolge, aber ansonsten scheint es großartig zu sein.

@ivanov , ping mich an, wenn du Bezug auf meine

Geschlossen von #10373 und zurückportiert als #10463

Hallo, gibt es nach Abschluss dieses Problems eine Möglichkeit, prompt_toolkit vollständig zu deaktivieren?

Hallo, gibt es bei geschlossenem Problem eine Möglichkeit, prompt_toolkit vollständig zu deaktivieren?

ja, wenn Sie der Satz TerminalIPythonApp.interactive_shell_class zu rlipython in Ihrer Konfigurationsdatei, dann prompt_toolkit sollte nicht einmal importiert werden. Die Readme-Datei von rlipython enthält weitere Informationen dazu.

Für alle, die dieses Thema noch abonniert haben: Ich habe gerade rlipython Version 0.1.0 veröffentlicht, Sie können jetzt pip install rlipython und die alte Readline standardmäßig in IPython zum Laufen bringen, nachdem Sie import rlipython; rlipython.install() .

Zu spät zur Party, aber lassen Sie mich wiederholen, dass RT derzeit ein No- Go für Projekte ist, die Module haben, die nicht für die Multithread-Initialisierung ausgelegt sind, siehe Sage's

Außerdem ein Kommentar zu einem allgemeinen Problem mit dem aktuellen RT: Es löst den Multithread-Import von Python-Modulen während der Tab-Vervollständigung aus. Wir bezweifeln sehr, dass es sicher ist.

Zu guter Letzt - da die IPython-Tab-Vervollständigung Segfaults verursacht, wie wäre es mit einem Mittel zum nicht-interaktiven Testen?

@jonathanslenders Haben Sie Probleme mit der Fertigstellung in einem separaten Thread? Gibt es eine Option, um es synchron laufen zu lassen?

Hallo @takluyver ,

Entschuldigung für die späte Antwort. Ich habe letzten Monat geheiratet und war daher eine Weile offline. ;)

Ich arbeite an prompt_toolkit 2.0, das bereits sowohl synchrone (im Hauptthread) als auch asynchrone (in anderen Threads) Vervollständigung unterstützt. Ich arbeite seit fast einem Jahr an 2.0 und hoffe, das in ein paar Monaten veröffentlichen zu können.

Für die synchrone Vervollständigung müssen Sie bedenken, dass, wenn der Vervollständiger nicht superschnell ist, dies nach jedem Tastendruck eine Verzögerung einführt (wenn Sie während des Tippens die vollständige Eingabe aktiviert haben). Ich glaube, dass Jedi zum Beispiel nicht superschnell ist.

Ich weiß, dass bestimmte Bibliotheken einige Probleme mit der asynchronen Vervollständigung haben. Ich denke, wir sollten die Autoren dieser Bibliotheken ermutigen, sicherzustellen, dass der Import überhaupt von jedem Thread aus erfolgen kann. In Zukunft würde ich es zu einer Option machen, die Vervollständigungssynchronisierung oder -asynchronisierung auszuführen, aber immer noch die standardmäßige asynchrone Vervollständigung vorziehen. Es macht die Benutzererfahrung so viel schöner.

Am Samstag, 21. Oktober 2017 um 14:47 Uhr, Jonathan Slenders < [email protected]

schrieb:

Ich weiß, dass bestimmte Bibliotheken einige Probleme mit asynchronem haben
Fertigstellung. Ich denke, wir sollten die Autoren dieser Bibliotheken ermutigen,
Stellen Sie sicher, dass der Import von jedem möglich ist
Gewinde.

IMHO ist es Wunschdenken, dass dies immer leicht zu erreichen ist.
Es gibt Python-Bibliotheken, die im Grunde sehr komplexe 3.
Partycode und Änderungen, die für eine threadsichere Initialisierung erforderlich sind, müssen
stromaufwärts gemacht.
Ein konkretes Beispiel, bei dem wir uns die Köpfe einschlagen
ist Maxima in einer (in Python eingebetteten) Lisp-System-ECL ausgeführt.
Letzteres benötigt wie alle Lisps einen Garbade-Sammler und verwendet BoehmGC . Auf einigen Plattformen muss letzteres sein
im Hauptthread initialisiert---oder war es früher so, zB für
FreeBSD, bis ich darauf hingewiesen habe, und es wurde schnell behoben . Wie Sie sich vorstellen können, in anderen
Fällen konnte man mit einer solchen Lösung völlig Pech haben, da man dafür Experten brauchte
Kenntnis eines recht komplizierten Systems.

Und es gibt mehrere Probleme, die gelöst werden müssen, darunter das in a
Single-Thread-Szenario eine Bibliothek ihre eigene Signalverarbeitung durchführen kann, während
in einem Multithread-Szenario muss die Signalverarbeitung zentralisiert werden. Die
Ein anderer, noch schwieriger zu behebender, ist, dass dieser Drittanbietercode möglicherweise nicht verfügbar ist
fadensicher.
(Um auf das obige Beispiel zurückzukommen, sehen wir all dies ...)

Es scheint, dass die beste Option wäre
damit PT alle Importe im Hauptthread durchführt --- ich habe keine Ahnung, ob
es ist jedoch einfach oder sogar machbar.

Abschließend möchte ich darauf hinweisen, dass PT tatsächlich einen Multithread-Import durchführt.
Da das Importieren bei großen Systemen ein Start-Engpass ist, ist es sehr
verlockend, Multithread-Import zuzulassen.
Ich würde wirklich gerne hören, was CPython-Leute dazu sagen würden; ich
wird nicht überrascht sein, wenn die Antwort wäre, dass es nicht gemacht werden darf.

PS. Ich will dir die Flitterwochen nicht ruinieren, herzlichen Glückwunsch :-)

Herzliche Glückwünsche! Natürlich brauchen Sie sich nicht zu entschuldigen - wir bekommen Ihre großartige Bibliothek kostenlos, also muss jeder Support so sein, wie es Ihnen passt. Beste Grüße an Sie und Ihren Partner.

Ich denke, wir werden wahrscheinlich auf synchrone Vervollständigungen umstellen, wenn sie verfügbar sind. Wir verwenden keine vollständige Eingabe, da wir die Verlaufssuchfunktion aktivieren, die sich damit gegenseitig ausschließt.