Ipython: リードライン機能を復活させますか？

これを6.0に戻すための作業を喜んで行うので、ここで＃10329にタグを付けます。

これは特に重要な問題だと思います。なぜなら、IPythonの長年のユーザーや支持者は、現在のIPython 5に不満を感じているか、使用したくないと感じているからです。

ほとんどのコードが削除されており、readlineを再統合するために多大な労力がかかる可能性がありますが、オプションとして追加して戻すことができてうれしいです。

それをオプションにする方法を理解できれば（リバイバルによって導入された潜在的なバグを修正するためにコアよりも速く進化できるように、それは素晴らしいことです。

RLを戻す場合は、＃10356を遅らせたいと思うかもしれません。

＃9260も参照してください。

そして、＃9399は削除の大部分です。

私はこれについて強く-1です。 readlineを廃止したとき（そしてさらに多くの削除に取り組んでいます）、ほとんどのユーザーのユーザーエクスペリエンスを劇的に改善しながら、多くのコードと複雑さを削除することができました。 リードラインオプションを復活させると、両方のインターフェイスが複雑になり、永久に維持されます。 これほど大きな変更を行うと一部のワークフローが破損することは常にわかっていましたが、これは正味の改善であると確信しており、2つの代替端末インターフェイスを維持するビジネスに携わってほしくありません。

私はむしろ私たちがしたい：

1. 切り替えの障害を取り除くために、IPythonとprompt_toolkitの両方で改善できるすべての作業を続けます。 ジョナサンは、PTKに関連する問題について彼にpingを送信するたびに、一般的に非常に敏感で親切でした。したがって、必要な変更を受け入れる可能性は十分にあると思います。 これには、カスタムショートカットの設定方法の文書化の改善や、 .inputrc読み取りの実験などが含まれます（ただし、他の場所で説明した理由により、デフォルトではオフのオプションでした）。 人々にreadlineに戻る簡単なオプションを提供すれば、これらの改善は起こりません。
2. readlineの使用を本当に主張する人がまだいる場合は、ターミナルインターフェイスを提供するrlipythonような別のパッケージをスピンアウトしますが、公式にサポートしているものではなく、コミュニティが維持していることを明確にします。

Windowsのpyreadlineには常に多くの問題があったことを考えると（特に、標準のPython REPLとIPythonにグローバルに影響を与えたという事実）、（py）readlineを必要としないことがデフォルトのままであることが望ましいです。少なくともWindowsでは。 ユーザーがpyreadlineを手動でインストールして有効にすることを好む場合、それは問題ありませんが、IPythonはpyreadlineが存在しなくても機能し、通常のインストールの依存関係として含まないようにする必要があります。

readlineの使用を本当に主張する人がまだいる場合は、ターミナルインターフェイスを提供するrlipythonのような別のパッケージをスピンアウトしますが、公式にサポートしているものではなく、コミュニティが維持していることを明確にします。

以前の動作を復元するIPythonとの統合（フラグやenv変数など）があると思いますが、それは合理的だと思います。 目標は、IPython readlineに依存するスクリプトとレシピをすでに十分に普及させ、単純なスイッチで機能させることです。

私の推測では、TerminalInteractiveShellクラスにトレイトレットを使用させるIPythonAppの単純な構成に加えて、既知の外部パッケージに事前設定された値を持つ--readlineフラグで十分であると思います。

個別のパッケージとしてのipythonでは、IPython 6をブロックせず、必要に応じて高速の反復サイクルを取得することもできます。

人々にreadlineに戻る簡単なオプションを提供すれば、これらの改善は起こりません。

それが完全に真実だとは思えません。 マルチライン、ハイライト、そして今や完成は、PTKインターフェースの大きな利点です。 また、RL / PTKの両方を並行して使用することさえできないために4.xに固定しているユーザーには、動作をスムーズにするためのIPython / PTKへのインセンティブ送信パッチがありません。

サポートされているオプションのように見えるため、スイッチと統合しません。ここでバグを報告します。 rlipythonはとにかくipython --readlineよりもタイピングが少なく、人々がそれをipythonとして使用したい場合は、エイリアスを作成できます。

ctrl-rの現在の経験についてのメモ：

Bashでは、ctrl-rを押してからEscキーを押すと、終了します。

これでは、検索領域を閉じる必要があるときに何もしません。

ctrl-rの現在の経験についてのメモ：
Bashでは、ctrl-rを押してからEscキーを押すと、終了します。
これでは、検索領域を閉じる必要があるときに何もしません。

これは簡単に修正できますが、完全ではありません。

 ~/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)

それは機能しますが、新しいキーを押すまでI-search-backward:は表示されたままになります。 この新しいキーは、後方検索が却下された場合と同じように動作しますが、非常に奇妙に感じます。

これを開いてくれてありがとう、@ ivanov！ 詳細についてはもう少し注意深く検討します。また、このリストに関するフィードバックをさらに増やすことをお勧めします。 それは明らかにトリッキーなバランスと論争であり、したがって、より多くの声が少なくとも私たちの決定プロセスに情報を与えることができるという良い兆候です。

@Carreauは、削除されたコードをIPythonに適切にCarreau / rlipythonで古いreadlineベースのコードだけを使用して新しいプロジェクトを作成し、ユーザーができるようにする＃10373を作成しました。この作品をカスタマイズします。

参考：メーリングリストに記載されている問題：

少なくともSMCでは、複数で貼り付けようとすると、主に質問します
最初の行に貼り付けて、すべてを黙って

（つまり、term.js）。 しかし、それはかなりイライラします。

これは、この端子がブラケットペーストをサポートしていないことを示しています。
IMHO：最近では、どの端末からもサポートされることが期待できると思います： https ：//cirw.in/blog/bracketed-paste（少なくともprompt_toolkitでは、複数行のテキストを貼り付けるために括弧で囲まれた貼り付けが必要になります）。

再度readlineサポートを追加する価値があるかもしれませんが、言及されたバグの複数はすでに修正されているか、修正されることに注意してください。 最大の問題はおそらくEmacsターミナル（実際にはxterm互換のターミナルではなく、サポートされることはありません）であり、最終的には.inputrcサポートが提供されますが、私の側の帯域幅/優先度の問題のため、しばらく時間がかかります。

いずれにせよ、ユーザーエクスペリエンスの問題を報告し続けてください。 これは重要。

@pfmooreそれは良い点です。 pyreadlineの欠如によってWindows環境が傷ついているのではないかと思います。 リードラインUIを復活させる場合、IPythonであろうとrlipythonパッケージであろうと、「true」リードラインに対してのみこれを行うことはおそらく理にかなっています。

個別のrlipythonパッケージの利点の1つは、既存のIPython 5リリースで使用できることですが、IPython自体で使用すると、明らかに新しいIPythonリリースでのみ機能します。

＃9799をprompt_toolkitのデフォルトの不快感のもう1つの原因として追加したいと思います。 インストールする追加の外部パッケージに完全に満足しています。

pyreadlineはWindowsの苦痛ですが、prompt-toolkitにも問題があります。 したがって、2つの不十分なソリューションの間では、「技術的負債」の少ないソリューションが最良のソリューションのように見えます。それは、prompt-toolkitです。

重要なのは、prompt_toolkitは一部の人にとっては優れており、readlineは他の人にとっては優れているということです。 だから問題は、余分なコードを維持することを避けるために、readlineの人々を緩める必要があるのか​​ということです。

pyreadlineはWindowsの苦痛ですが、prompt-toolkitにも問題があります。 したがって、2つの不十分なソリューションの間では、「技術的負債」の少ないソリューションが最良のソリューションのように見えます。それは、prompt-toolkitです。

重要なのは、prompt_toolkitは一部の人にとっては優れており、readlineは他の人にとっては優れているということです。 だから問題は、余分なコードを維持することを避けるために、readlineの人々を緩める必要があるのか​​ということです。

現在、添付のPR（＃10373）は4行であり、構成オプションにするための構成オプションにすぎないことに注意してください。 readlineコードはIPythonにはなく、拡張機能になります。

本当の質問は：

• A：readline-ipythonが別のスペルの別の実行可能ファイルである場合は問題ありません。
• B：または、IPythonにシェルアウトするスクリプトと拡張機能（emacsなど）の場合、IPython構成オプションである必要があります。

どちらの場合も、readlineはIPythonの依存関係になりません。

これは、IPythonで維持するのが簡単ないくつかの機能に影響を与えますが、現在の主な競合はAまたはBです。

emacs側からはどちらでも構いません。 Bは長期的にはより柔軟に見えます。

readlineを好む私たちにとっては、IPythonシェルアウトのreadlineも必要だと思います-つまりBです。

私はしばらくの間これについて考えていて、私が直接従事する機会があったチームの何人かの人々と話していました。 これが私の見解です。 私はまだ最終決定を呼び出していないんだけど、私は近い解像度に私たちを移動しようとしてに非常に感謝していることを強調したいと思います。それは、ほとんどの場合、驚くべき、モダンで高品質のユーザーエクスペリエンスを提供してくれるからです。 当面の問題について：

• readlineを必要とするユーザーの懸念は非常に現実的であり、コストがIPython内またはその周辺に余分なコードを運ぶ場合でも、今すぐ彼らに適した解決策を見つける必要があると思います。

• PTチームと協力して、それが問題となるreadlineとの機能の同等性に向けて改善していきます（RLにはない機能の膨大なコレクションがあることを私は知っています）。

• PTがさらに改善されたとしても、私はまだ昔ながらのreadlineが価値がある状況を見ることができます。 PTは、その洗練されたおかげで、Emacs内のipythonシェル内のssh上でtmux内を実行すると、遅くなるか、より脆弱になる可能性があります。 これは、私たちが十分にサポートする必要があり、以前は有効だったユースケース

これを考えると、良い妥協案は@Carreauが彼のPRで提案したものに沿っていると思います。

• readlineをサポートしていますが、ユーザーが手動でインストールする必要があるサードパーティのパッケージを介してのみサポートしています。

• ユーザーは、構成ファイルでこのパッケージの使用を設定するか、コマンドラインで呼び出すか、シェルエイリアスまたは小さなラッパースクリプトを作成できます。 はい、これにはこのコーナーケースのユーザー側で少し余分な作業が必要ですが、最小限のコストでクリーンなソリューションを提供し、PTを使用できる（そしてその機能の恩恵を受ける）ユーザーの大多数は中断することなくそうし続けます。

これは、この追加パッケージをしばらくの間サポートすることを意味しますが、それほど多くの作業が行われるとは思いません。そのコードはしばらくの間ほとんど変更されておらず、多くの新機能を追加することについては話していません。 既存の過去のベースライン動作との互換性を維持するだけです。

私がやや重要だと思う1つのコストは、（@ Carreauによって言及されている）これにより削除できなくなるコードを削除したい場合があるということです。 少なくとも今のところ、ユーザーの利益のために支払うべき代償だと思います。 将来、考えられるすべてのケースでPTがRLの100％の代替となる状況に本当に気付いた場合は、再検討することができます。 しかし今のところ、ユーザーの一部のサブセットの利益のために少し古くなった特別な目的のコードを保持することは正しいことです。 何年にもわたって、複数の種類の特殊なケースのコード（windows、py2 / 3など）がありましたが、将来もそうなると確信しています。 ユーザーのワークフローを提供することは、コードのクリーンアップよりも優先されるべきだと思います（この状況では、包括的なステートメントを作成しないでください）。

これはどのように聞こえますか？

ところで、この「修正」は5.xシリーズにバックポートする必要があると思います。どちらかといえば、まだpython 2.xを使用しているユーザーの数は、古いサーバーでリモートで作業しているユーザーの数とかなり重複していると思います。 したがって、私の投票は、外部パッケージをpython 2-3互換にし、コードのipython側を5.xにバックポートすることです。

応答に時間を割いてくれて、特に何人かの人々に連絡してくれて、フェルナンドに感謝します。
PRの磨き上げ、マージ、5.0へのバックポートに取り組みます。

リードラインインターフェイスの保守に関心のある人のために、GitHubでrlipythonを使用しています。 私はそれを維持せず、PyPIで公開しませんが、それを歓迎します。組織が必要な場合は、これをhttps://github.com/ipython-contribに移動することをお勧めします。 。

ありがとう ！

実際、これをメインのIPython組織でホストし、pypiに配置する必要があると思います。 また、次のように、コミュニティにもう少し歓迎のメッセージを送ることもできます。

これは、過去の互換性と、メインインターフェイス（prompt-toolkit）が最適でない特定のユースケースをサポートするために提供するものです。 ただし、重大なバグの修正以外の重要な開発は想定していません。 これをベストエフォートソリューションとして提供するためのリソースしかありません。 このツールの重要な開発に関心がある場合は、問題を介してお知らせください。パッケージのメンテナンスをお客様に譲渡することを検討できます。」

@ivanovがこの方向に進むための数サイクルを持っているなら、

これまでの作業を推進してくれた@Carreauに感謝します！

みんな、特に@Carreauにrlipython上げてくれてありがとう。 私はそれに取り組み始め、それを形に整え始めました。 誰かがそれを見逃した場合に備えて、それは現在ipython / rlipythonの下にあります。 作業を開始してから2週間以内にリリースをリリースするように努めますが、今のところは機能していると言えます。 現在、既知の問題が1つあります。ipython/ rlipython＃3で追跡しているIn / Outプロンプトが色付けされていませんが、それ以外はすばらしいようです。

@ivanov 、あなたが手が欲しいならそれについて私にpingしてください...私は上で提供しました、しかし私はここ数週間の私の時間の可用性について少しナイーブでした。 それでも、これがすべてのcmdラインユーザーにとって確実な解決策に到達するのを助けたいので、あなたが手を必要とするなら、私はまだ積極的に参加します（そしてそうすることを楽しんでいます:)

＃10373でクローズされ、＃10463としてバックポートされました

こんにちは、この問題を解決しましたが、 prompt_toolkit完全に無効にする方法はありますか？

こんにちは、この問題を解決しましたが、prompt_toolkitを完全に無効にする方法はありますか？

はい、設定ファイルでTerminalIPythonApp.interactive_shell_classをrlipythonに設定した場合、prompt_toolkitもインポートしないでください。 rlipythonのreadmeには、これを行う方法の詳細が記載されています。

誰のためにも、この問題に加入：私はちょうど解放rlipythonバージョン0.1.0を、あなたができる今pip install rlipythonとあなたが後にIPythonで、デフォルトでは古いのreadlineの作業を取得import rlipython; rlipython.install() 。

パーティーに遅れましたが、マルチスレッド初期化用に設計されていないモジュールを持つプロジェクトでは、現在のところRTはノーノーですチケット22766を参照してください。 （そして、これが私たちがセージでそれについて何かをする必要がある主な理由です）。

同様に、現在のRTの一般的な問題についてのコメント：タブ補完を実行しているときにPythonモジュールのマルチスレッドインポートをトリガーします。 私たちはそれが安全であると非常に疑っています。

最後になりましたが、IPythonタブ補完によりセグフォールトが発生することを考えると、非対話型テストの手段はどうでしょうか。

@jonathanslendersは、別のスレッドで実行されている完了に関する問題に遭遇しましたか？ 同期して実行するオプションはありますか？

こんにちは@takluyver 、

返信が遅れてすみません。 私は先月結婚したので、しばらくオフラインになっています。 ;）

私は、同期（メインスレッド）と非同期（他のスレッド）の両方の完了をすでにサポートしているprompt_toolkit2.0に取り組んでいます。 私は2.0にほぼ1年間取り組んできましたが、2、3か月以内にリリースしたいと思っています。

同期完了の場合、コンプリーターが超高速でない場合、すべてのキーストロークの後に遅延が発生することに注意する必要があります（入力中に完了している場合）。 たとえば、ジェダイは超高速ではないと思います。

特定のライブラリには非同期補完に関するいくつかの問題があることを私は知っています。 これらのライブラリの作成者には、そもそもどのスレッドからでもインポートできるようにすることをお勧めする必要があると思います。 将来的には、補完の同期または非同期を実行するオプションを作成する予定ですが、デフォルトでは非同期の補完を使用することをお勧めします。 それはユーザーエクスペリエンスをとても良くします。

2017年10月21日土曜日午後2時47分、Jonathan Slenders < [email protected]

書きました：

特定のライブラリに非同期に関するいくつかの問題があることを知っています
完了。 これらのライブラリの作者に次のことを勧めるべきだと思います
そもそもそれらのインポートがどこからでも実行できることを確認してください
スレッド。

私見では、これはいつでも簡単に達成できると考えています。
基本的に非常に複雑な3番目をラップしているPythonライブラリがあります
パーティコード、およびスレッドセーフな初期化に必要な変更は
上流で行われます。
私たちが頭を叩いている具体的な例
Maximaは（Pythonに組み込まれた）LispシステムECLで実行されます。
後者は、すべてのLispと同様に、ガーベードコレクターを必要とし、 Boehmを使用していますGC 。 一部のプラットフォームでは、後者は
メインスレッドで初期化---または以前はそうでした。
FreeBSD、私がそれを指摘するまで、そしてそれはすぐに修正されました。 あなたが想像できるように、他の
専門家が必要だったので、そのような修正では完全に運が悪い場合があります
非常に複雑なシステムの知識。

そして、解決すべきいくつかの問題があります。そのうちの1つは
シングルスレッドシナリオでは、ライブラリは独自の信号処理を実行できますが、
マルチスレッドのシナリオでは、信号処理を一元化する必要があります。 NS
他の、解決するのがさらに難しいのは、そのサードパーティのコードがそうではないかもしれないということです
スレッドセーフ。
（上記の例に戻ると、これらすべてが表示されます...）

最良の選択肢は
PTがメインスレッドですべてのインポートを実行するために---私にはわかりません
ただし、実装は簡単であり、実現可能ですらあります。

最後に、事実上、PTはマルチスレッドインポートを実行することを指摘しておきます。
インポートは大規模なシステムのスタートアップのボトルネックであるため、非常に
マルチスレッドインポートを許可したい。
CPythonの人々がそれについて何を言うか本当に聞きたいです。 私
答えがそれが行われてはならないということであったとしても驚かないでしょう。

PS。 私はあなたの新婚旅行を台無しにするつもりはありません、おめでとうございます:-)

おめでとう！ もちろん、お詫びする必要はありません。すばらしいライブラリを無料で入手できるので、いつでも都合のよいときにサポートを提供する必要があります。 あなたとあなたのパートナーに最高の願いを。

同期完了が利用可能になったら、同期完了に切り替える可能性が高いと思います。 相互に排他的な履歴検索機能を有効にするため、完全入力は使用しません。