Ipython: Вернуть возможность чтения строки?

Я готов поработать, чтобы вернуть это вовремя к версии 6.0, поэтому я помечу здесь # 10329.

Я думаю, что это особенно важная проблема, потому что давние пользователи и сторонники IPython разочарованы или даже не хотят использовать IPython 5, как сейчас.

Я счастлив добавить это обратно как вариант, хотя большая часть кода была удалена, и, вероятно, потребуется много усилий для реинтеграции строки чтения.

Если бы мы смогли выяснить, как сделать это необязательным (чтобы он мог развиваться быстрее, чем ядро, чтобы повторно исправить потенциальную ошибку, появившуюся в результате возрождения, это было бы здорово.

Мы можем отложить # 10356, если вернем RL.

См. Также # 9260.

И # 9399 - это основная часть удаления.

Я категорически против. Мы смогли избавиться от большого количества кода и сложности, когда отказались от строки чтения (и мы работаем над тем, чтобы убрать еще больше), при этом значительно улучшив взаимодействие с пользователем для большинства пользователей. Если мы вернем опцию чтения строки, у нас будет вся сложность обоих интерфейсов, чтобы поддерживать ~ вечно. Мы всегда знали, что такое серьезное изменение нарушит некоторые рабочие процессы, но я уверен, что это чистое улучшение, и я не хочу, чтобы мы занимались поддержкой двух альтернативных терминальных интерфейсов.

Я бы предпочел, чтобы мы:

1. Продолжайте работать над всем, что мы можем улучшить как в IPython, так и в prompt_toolkit, чтобы устранить препятствия для переключения. Джонатан в целом был впечатляюще отзывчивым и полезным всякий раз, когда мы писали ему о проблемах, связанных с PTK, поэтому я думаю, что у нас есть хорошие шансы добиться принятия любых необходимых нам изменений. Это включает в себя такие вещи, как лучшее документирование того, как устанавливать собственные ярлыки, и, возможно, эксперименты с чтением .inputrc (хотя я бы предпочел, чтобы это был вариант по умолчанию, по причинам, которые я объяснил в другом месте). Если мы дадим людям возможность легко вернуться к строке чтения, этих улучшений не произойдет.
2. Если все еще есть люди, которые действительно настаивают на использовании readline, разверните отдельный пакет, например rlipython который предоставляет интерфейс терминала, но четко укажите, что это поддерживается сообществом, а не тем, что мы официально поддерживаем.

Учитывая, что с pyreadline в Windows всегда был ряд проблем (не в последнюю очередь, тот факт, что он повлиял на стандартный Python REPL, а также на IPython), я бы предпочел, чтобы не требующая (py) readline оставалась по умолчанию, в по крайней мере в Windows. Если пользователь предпочитает устанавливать pyreadline вручную и включать его, это нормально, но IPython должен работать без pyreadline и не включать его как зависимость от обычной установки.

Если все еще есть люди, которые действительно настаивают на использовании readline, создайте отдельный пакет, такой как rlipython, который предоставляет интерфейс терминала, но четко укажите, что это поддерживается сообществом, а не тем, что мы официально поддерживаем.

Я думаю, что это разумно, хотя я считаю разумной некоторую интеграцию (например, флаг и / или переменную env) с IPython, которая восстанавливает предыдущее поведение. Цель состоит в том, чтобы иметь уже хорошо распространенные сценарии и рецепты, которые полагаются на строку чтения IPython, все еще работающую с простым переключателем.

Я предполагаю, что простой конфигурации в IPythonApp, которая заставляет класс TerminalInteractiveShell использовать трейтлет, плюс флаг --readline, который имеет предустановленное значение для известного внешнего пакета, будет достаточно.

Ipython как отдельный пакет также позволит не блокировать IPython 6 и при необходимости получить быстрый цикл итерации.

Если мы дадим людям возможность легко вернуться к строке чтения, этих улучшений не произойдет.

Я сомневаюсь, что это полностью правда. Многострочность, выделение, а теперь и завершение - все еще большое преимущество интерфейса PTK. А у пользователей, которые прикрепляются к 4.x, потому что они даже не могут использовать RL / PTK параллельно, нет стимула отправлять патч в IPython / PTK, чтобы сгладить поведение.

Я бы не стал интегрировать его с переключателем, потому что это делает его похожим на поддерживаемый вариант, и люди будут сообщать об этом здесь. rlipython любом случае меньше набирает, чем ipython --readline , и если люди хотят использовать его как ipython , они могут использовать псевдоним.

Просто примечание о текущем опыте использования ctrl-r :

В Bash, когда вы нажимаете ctrl-r, а затем нажимаете escape, он выдает вас.

В этом случае он ничего не делает, когда должен закрыть область поиска.

Просто примечание о текущем опыте использования ctrl-r:
В Bash, когда вы нажимаете ctrl-r, а затем нажимаете escape, он выдает вас.
В этом случае он ничего не делает, когда должен закрыть область поиска.

Это легко исправить, но не полностью:

 ~/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! Я собираюсь более подробно остановиться на деталях, я также собираюсь поощрять больше отзывов по этому списку. Очевидно, что это сложный баланс и споры, поэтому хороший знак того, что большее количество голосов может, по крайней мере, проинформировать наш процесс принятия решений.

Просто обновленная информация о возможных дальнейших действиях в этом направлении: вместо того, чтобы переносить удаленный код в IPython, строки чтения в

К вашему сведению: проблема, описанная в списке рассылки:

Я спрашиваю в основном потому, что хотя бы в SMC, если вы попытаетесь вставить несколько
строки он вставляет в первую строку и молча игнорирует всееще . Это может быть проблема с уровнем поддержки xterm в SMC.
(то есть term.js). Однако это довольно неприятно.

Это означает, что данный терминал не поддерживает вставку в скобках.
ИМХО: я думаю, что в наши дни мы можем ожидать от любого терминала его поддержки: https://cirw.in/blog/bracketed-paste (по крайней мере, для prompt_toolkit потребуется вставка в скобках для вставки многострочного текста.)

Возможно, стоит снова добавить поддержку readline, но обратите внимание, что многие из упомянутых ошибок уже исправлены или будут исправлены. Самыми большими проблемами, вероятно, являются терминал Emacs (который на самом деле не является xterm-совместимым терминалом и никогда не будет поддерживаться) и поддержка .inputrc, которая в конечном итоге появится, но из-за проблем с полосой пропускания / приоритета с моей стороны займет некоторое время.

В любом случае продолжайте сообщать о проблемах с пользовательским интерфейсом. Это важно.

@pfmoore , это хороший rlipython .

Одним из преимуществ отдельного пакета rlipython является то, что его можно использовать с существующей версией IPython 5, тогда как выполнение этого в самом IPython, очевидно, будет работать только для новых выпусков IPython.

Я хотел бы добавить # 9799 в качестве еще одного источника неудобства при использовании настроек по умолчанию prompt_toolkit. Я был бы полностью счастлив, если бы установил дополнительный внешний пакет.

pyreadline - это боль в Windows, но с инструментарием подсказок также есть проблемы. Таким образом, между двумя неудовлетворительными решениями, решение с меньшим «техническим долгом» выглядит как лучшее решение: prompt-toolkit.

Я думаю, что суть в том, что prompt_toolkit лучше для некоторых людей, а readline лучше для других. Итак, вопрос в том, нужно ли сокращать людей, читающих линию, чтобы избежать поддержки лишнего кода?

pyreadline - это боль в Windows, но с инструментарием подсказок также есть проблемы. Таким образом, между двумя неудовлетворительными решениями, решение с меньшим «техническим долгом» выглядит как лучшее решение: prompt-toolkit.

Я думаю, что суть в том, что prompt_toolkit лучше для некоторых людей, а readline лучше для других. Итак, вопрос в том, нужно ли сокращать людей, читающих линию, чтобы избежать поддержки лишнего кода?

Обратите внимание, что прямо сейчас прикрепленный PR (# 10373) состоит из 4 строк и является просто вариантом конфигурации, чтобы сделать его вариантом конфигурации. Код readline даже не будет в IPython и будет расширением.

Настоящий вопрос:

• О: Ничего страшного, если readline-ipython является отдельным исполняемым файлом с другим написанием.
• B: Или для скриптов и расширений, которые выводят оболочку на IPython (например, emacs), если это опция конфигурации IPython.

В обоих случаях строка чтения не будет снова зависеть от IPython.

Это действительно влияет на несколько функций, которые проще сохранить в IPython, но сейчас основное разногласие - A или B.

Со стороны emacs тоже все в порядке. B кажется более гибким в долгосрочной перспективе.

Я думаю, для тех из нас, кто предпочитает readline, мы хотели бы также использовать readline для обстрела IPython - так что B.

Я думал об этом некоторое время и разговаривал с несколькими людьми из команды, с которыми мне довелось пообщаться лично. Вот мое мнение по этому поводу. Я еще не называя окончательное решение, но я пытаюсь приблизит нас к решению. Кстати, я хочу подчеркнуть, что я очень благодарен команде Prompt Toolkit, поскольку в подавляющем большинстве случаев она дает нам потрясающий, современный и высококачественный пользовательский интерфейс. По рассматриваемому вопросу:

• Проблемы пользователей, которым требуется readline, вполне реальны, и я думаю, что сейчас мы должны найти для них хорошее решение, даже если затраты связаны с переносом некоторого дополнительного кода в / вокруг IPython.

• Мы продолжим работать с командой PT, чтобы улучшить его в направлении обеспечения паритета функций с readline, где это проблема (я знаю, что у него есть обширный набор функций, которых нет в RL).

• Даже если PT улучшится и дальше, я все равно вижу ситуации, в которых старая обычная строка чтения будет полезна. PT, в силу своей сложности, скорее всего, будет медленнее или более хрупким, если, скажем, работать внутри tmux через ssh в оболочке ipython внутри Emacs. Это допустимый вариант использования, который мы должны хорошо поддерживать и к которому мы привыкли.

Учитывая это, я думаю, что хорошее компромиссное решение похоже на то, что

• мы поддерживаем readline, но только через сторонний пакет, который должен быть установлен пользователем вручную.

• затем пользователь может либо установить использование этого пакета в своем файле конфигурации, либо вызвать его из командной строки, либо написать псевдоним оболочки или крошечный сценарий оболочки. Да, это требует дополнительной работы со стороны пользователей этого углового случая, но это дает им чистое решение с минимальными затратами, в то время как большинство пользователей, которые могут использовать PT (и извлекать выгоду из его функций), продолжают делать это без перебоев. .

Это означает, что какое-то время будет поддерживать этот дополнительный пакет, но я не думаю, что это будет так много работы: этот код практически не изменился за долгое время, и мы не говорим о добавлении большого количества новых функций. Простое поддержание совместимости с существующим историческим базовым поведением.

Единственная цена, которую я считаю довольно значительной, заключается в том, что (упомянутая @Carreau) может быть код, который мы хотели бы вырвать, и это помешало бы нам удалить. Я считаю, что это цена, которую мы должны заплатить на благо наших пользователей, по крайней мере, на данный момент. Если когда-нибудь в будущем мы действительно окажемся в ситуации, когда PT является 100% заменой RL во всех мыслимых случаях, мы можем вернуться к этому. Но на данный момент правильным решением является сохранение немного устаревшего специализированного кода на благо некоторой части наших пользователей. За прошедшие годы у нас было несколько типов кода для особых случаев (windows, py2 / 3 и т. Д.), И я уверен, что мы снова будем это делать в будущем. Я думаю, что обслуживание рабочих процессов наших пользователей должно иметь приоритет перед очисткой кода (в этой ситуации не делать общих заявлений).

Как это звучит?

Кстати, я думаю, что это «исправление» должно быть перенесено в серию 5.x: во всяком случае, я подозреваю, что количество пользователей, все еще использующих python 2.x, хорошо пересекается с людьми, работающими удаленно на старых серверах. Таким образом, я бы проголосовал за то, чтобы внешний пакет был совместим с python 2-3, а также за обратный перенос части кода ipython на 5.x.

Спасибо, Фернандо, что нашел время ответить, и особенно за то, что обратился к нескольким людям.
Я буду работать над полировкой своего PR, объединю его и бэкпортирую на 5.0.

У меня есть rlipython на GitHub для всех, кто заинтересован в поддержке интерфейса readline. Я не буду поддерживать и публиковать его на PyPI, но вы можете это сделать, и было бы неплохо переместить его на https://github.com/ipython-contrib, если вам нужна организация. .

Спасибо !

Я действительно думаю, что мы должны разместить это в основной организации IPython и разместить его на pypi. Мы также можем отправить немного более приветливое сообщение сообществу, например:

это то, что мы предлагаем для поддержки исторической совместимости и определенных конкретных случаев использования, когда наш основной интерфейс (подсказка-инструментарий) не является оптимальным. Но мы не предвидим каких-либо значительных изменений, кроме исправления критических ошибок. У нас есть ресурсы только для того, чтобы предложить это как лучшее решение. Если вы заинтересованы в значительном развитии этого инструмента, сообщите нам об этом через проблему, и мы сможем рассмотреть вопрос о передаче вам сопровождения пакета ".

Если у @ivanov есть несколько циклов, которые нужно

Спасибо @Carreau за то, что продвинули работу так далеко!

Спасибо всем, особенно @Carreau за то, что rlipython . Я начал над этим работать и доводить до формы. На случай, если кто-то его пропустил, теперь он находится в ipython / rlipython . Я постараюсь выпустить релиз в ближайшие две недели, когда начну с ним работать, но пока могу сказать, что это работает! На данный момент есть одна известная проблема - сообщения In / Out не окрашиваются, что я отслеживаю в ipython / rlipython # 3, но в остальном это кажется отличным.

@ivanov , поводу , если вам

Закрыт номером 10373 и перенесен как # 10463

Привет, проблема закрыта. Есть ли способ полностью отключить prompt_toolkit ?

Привет, проблема закрыта, есть ли способ полностью отключить prompt_toolkit?

да, если вы установите TerminalIPythonApp.interactive_shell_class на rlipython в вашем файле конфигурации, то prompt_toolkit даже не следует импортировать. Readme rlipython дает больше информации о том, как это сделать.

Для тех, кто все еще подписан на эту проблему: я только что выпустил rlipython версии 0.1.0, теперь вы можете pip install rlipython и получить старую строку чтения, работающую по умолчанию в IPython, после того, как вы import rlipython; rlipython.install() .

Поздно к вечеринке, но позвольте мне повторить, что RT в настоящее время является запретом для проектов, в которых есть модули, не предназначенные для многопоточной инициализации, см. 22766 . (И это основная причина, по которой нам нужно что-то делать в Sage).

Также, комментарий к общей проблеме с текущим RT: он запускает многопоточный импорт модулей Python при выполнении табуляции. Мы очень сомневаемся, что это безопасно.

И последнее, но не менее важное: учитывая, что завершение вкладки IPython вызывает сбои, как насчет средства для его неинтерактивного тестирования?

@jonathanslenders сталкивались ли вы с какими-либо проблемами с завершением работы в отдельном потоке? Есть ли возможность сделать так, чтобы он работал синхронно?

Привет @takluyver ,

Извините за поздний ответ. Я вышла замуж в прошлом месяце, поэтому какое-то время не в сети. ;)

Я работаю над prompt_toolkit 2.0, который уже поддерживает как синхронное (в основном потоке), так и асинхронное (в другом потоке) завершение. Я работал над 2.0 почти год и надеюсь выпустить его через пару месяцев.

Для синхронного завершения вы должны иметь в виду, что если устройство завершения не очень быстрое, это приведет к задержке после каждого нажатия клавиши (если у вас включено завершение во время набора текста). Я считаю, что джедаи, например, не очень быстрые.

Я знаю, что в некоторых библиотеках есть проблемы с асинхронным завершением. Я думаю, мы должны поощрять авторов этих библиотек убедиться, что их импорт в первую очередь может быть выполнен из любого потока. В будущем я бы сделал возможным запускать синхронизацию или асинхронность завершения, но все же предпочел бы иметь асинхронное завершение по умолчанию. Это делает пользовательский опыт намного приятнее.

В субботу, 21 октября 2017 г., в 14:47, Джонатан Слендерс < [email protected]

написал:

Я знаю, что в некоторых библиотеках есть проблемы с асинхронным
завершение. Я думаю, мы должны побудить авторов этих библиотек к
убедитесь, что импортировать их в первую очередь можно из любого
нить.

ИМХО это выдавать желаемое за действительное, что этого всегда легко добиться.
Существуют библиотеки Python, которые в основном обертывают очень сложные 3-е
партийный код, и изменения, необходимые для поточно-ориентированной инициализации, должны быть
сделано вверх по течению.
Конкретный пример, мы бьемся головой
работает ли Maxima в (встроенной в Python) системе Lisp ECL.
Последнему, как и всем Lisp, нужен сборщик одежды, и он использует BoehmGC . На некоторых платформах последнее должно быть
инициализирован в основном потоке --- или это было так, например, для
FreeBSD, пока я не указал на это, и это было быстро исправлено . Как вы понимаете, в других
в некоторых случаях с таким исправлением может не повезти, так как для этого нужен эксперт
знание довольно сложной системы.

И есть несколько вопросов, которые необходимо решить, одна из которых связана с
однопоточный сценарий: библиотека может выполнять свою собственную обработку сигналов, тогда как
в многопоточном сценарии обработка сигналов должна быть централизованной. В
другое, что еще сложнее решить, заключается в том, что сторонний код может не
потокобезопасный.
(возвращаясь к примеру выше, мы видим все это ...)

Похоже, что лучшим вариантом будет
чтобы PT выполнял весь импорт в основном потоке --- я понятия не имею,
однако это легко или даже возможно реализовать.

Наконец, позвольте мне указать, что фактически PT выполняет многопоточный импорт.
Поскольку импорт является узким местом при запуске крупных систем, это очень
заманчиво разрешить многопоточный импорт.
Я действительно хотел бы услышать, что люди CPython скажут об этом; я
не удивлюсь, если ответ будет, что этого делать нельзя.

PS. Я не хочу испортить вам медовый месяц, поздравляю :-)

Поздравляю! Конечно, не нужно извиняться - мы получаем вашу потрясающую библиотеку бесплатно, поэтому любая поддержка должна быть в удобном для вас месте и тогда, когда вам это удобно. Наилучшие пожелания вам и вашему партнеру.

Думаю, мы, скорее всего, перейдем на синхронное завершение, когда они станут доступны. Мы не используем «полный по мере ввода», потому что мы включаем функцию поиска по истории, которая является взаимоисключающей с этим.