Ipython: Странный персонаж после первого импорта

Хм, я видел это, но с ^[[43;1R , но я предположил, что это произошло из-за того, что я был мастером своего эмулятора терминала. Не уверен, откуда это взялось

Я видел похожие вещи в последней версии https://github.com/jonathanslenders/pymux (не выпущен, использует prompt-toolkit 2). Может быть, у @jonathanslenders есть идеи?

Я получаю то же самое:

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

Если я затем попытаюсь завершить табуляцию:

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

Это делает завершение табуляции практически непригодным для использования.

Возможно ли, что это было исправлено следующей фиксацией: https://github.com/jonathanslenders/python-prompt-toolkit/commit/e226d640177aa1d2cf293e4de382f171586173a2 ?
Он объединен с мастером prompt_toolkit, но я собираюсь выпустить новый prompt_toolkit 2.0, который включает его.

Я установил prompt-toolkit из мастера, и проблема все еще существует, но я не уверен, нужно ли что-то еще делать на стороне ipython.

Нет, я почти уверен, что это не IPython. Попробую воспроизвести с iterm2

Я уверен, что не понимаю здесь сложностей, но просто для информации, это происходит с IPython 7.0 и 7.1, и не происходит с 6.0 или 6.5, тестирование в том же virtualenv.

Можете ли вы опубликовать, в каком терминале вы это видели?
Умею воспроизводить на iTerm2 - 3.2.1beta6 - osx; alacritty v0.2.0-35-ga53cabf osx, но не на голом macos terminal.app (sierra 10.12.6)

Может быть, это несоответствие рекламируемых функций терминала и того, что они на самом деле могут делать?

Это также не воспроизводится (для меня) с ipython --colors=nocolor

Просто откройте Terminal.app на High Sierra 10.13.6. nocolor не исправляет это для меня.

Это также не воспроизводится (для меня) с ipython --colors=nocolor

Поцарапайте это, это кажется случайным, но на самом деле nocolor не исправил это.

Не могли бы вы попробовать удалить этот patch_stdout менеджер контекста?

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

Удаление диспетчера контекста, похоже, исправляет это для меня.

Это происходит со мной либо в macOS Terminal.app, либо в iTerm2. Однако в iTerm2 3.2.1beta персонаж появлялся довольно последовательно. Сегодня утром я обновился до 3.2.2beta1, и теперь персонаж появляется и сразу исчезает, замененный обычным приглашением iPython. Но по крайней мере в одном случае персонаж был настойчивым, я не уверен, в чем разница.

Ага, исправил и для меня. Эффект у меня всегда был стабильным.

@jonathanslenders может быть так, что stdout патча имел состояние гонки и что stdout / err восстанавливаются и начинают записываться до того, как произошла очистка?

Параметр raw для patch_stdout, похоже, никуда не денется и в коде ptk.

Таким образом, есть причина для этого, иначе печать в фоновых потоках испортит рендеринг, но это выглядит (для меня), что это состояние гонки между сбросом захваченного stderr / out и восстановлением их начального значения.

Не уверен, локализовали ли вы ошибку или все еще экспериментируете, но для вашей информации:

• macOS 10.13.6
• iTerm 3.2.1 - всегда показывает ^[[41;1R после первого ввода (импорт, выражение, даже пустая строка)
• Terminal.app 2.8.2 (404) - отлично работает!

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

Я также получаю это (macOS 10.11.6, iTerm 3.2.0beta5) очень часто, хотя и не в 100% случаев, и с последовательностью 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]:

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

К сожалению, readline на данный момент недоступен: https://github.com/ipython/rlipython/issues/21

Нет изменений при текущем мастере prompt_toolkit (версия 2.0.5).

Я могу это воспроизвести.

iTerm2 build 3.2.3 (думаю последняя), IPython 7.0.1, Python 3.6.1.

У меня была ошибка с Python 3.6.3 в Ubuntu, и она исчезла с Python 3.7, хотя я вижу некоторые сбои (например, символы печатаются, а затем быстро удаляются).

У меня есть исправление: https://github.com/jonathanslenders/python-prompt-toolkit/commit/09de545476be985b95ae2690ef8393efdd65b7e5

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

• По какой-то причине пустая строка захватывается и записывается в стандартный вывод прямо перед принятием первого ввода. Это вызвало код patch_stdout. На самом деле не было необходимости стирать подсказку и рисовать ее снова, просто для того, чтобы напечатать пустую строку. (Мне все еще нужно выяснить, почему это происходит на самом деле.)

• Настоящее исправление - дождаться ответов CPR перед рендерингом захваченного контента. СЛР работает асинхронно. Мы запрашиваем позицию курсора, записывая что-то в stdout, и получаем ответ от терминала на stdin. Всегда есть небольшая задержка. Но важно держать терминал в режиме RAW и читать этот ввод, пока не придет ответ. Мы этого не сделали, и терминал отобразил собственный ответ с указанием позиции курсора.

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

Не могли бы вы все попробовать с последним коммитом prompt_toolkit? Если получится, выложу новый релиз.

Это исправляет ошибку с моей стороны. Спасибо, @jonathanslenders !

Да, большое спасибо, последний мастер исправил это и для меня.

Этот патч исправляет некоторые [[39;1R символы, которые у меня тоже были. Спасибо!

РЕДАКТИРОВАТЬ: Поцарапайте это. Я тестировал не ту версию. Да, мне кажется, это тоже поправляет.

Нет, похоже, это меня не решает. Вместо этого у меня другой персонаж

AlbireoProˇalbireo: Downloads » ipython                 (3.7.0 2.7.15)

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

^[[21;1RIn [2]:

Не могли бы вы все попробовать с последним коммитом prompt_toolkit? Если получится, выложу новый релиз.

работает для меня. Вы также меняете обработку цветов AFAICT, мы неохотно полагались на отображение ansi в код ansi в некоторых местах в IPython, я это тоже исправлю. Спасибо !

@Carreau : я только что запустил prompt_toolkit 2.0.6.
Ожидает ли IPython, что определенные последовательности RRGGBB соответствуют определенным цветам ANSI даже в 256-цветном режиме?

Кстати, @Carreau , одна из функций prompt_toolkit теперь - это возможность увеличивать / уменьшать яркость цветов. Это упрощает адаптацию к терминалам со светлым или темным фоном. Я добавил это в меню ptpython для тестирования (в интерактивном режиме), и он работает очень хорошо.

ожидать

Я бы не сказал «ожидать», но кажется, что в темах есть сочетание #ansixxx и #00ff00 которые хорошо смотрятся вместе, а с 2.0.6 они немного сильнее в своих различиях.

Я думаю, нам просто нужно больше согласованности в том, используем ли мы #ansi или #hex .

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

Интересно, но в этом есть смысл. Когда цвет определен как # 00ff00, я смотрю на ближайший цвет из 256 цветовой палитры, но исключаю 16 цветов ansi. Это означает, что он берет ближайший из оставшихся 240 цветов.

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

Вот пример того, как основные цвета ANSI отображаются в разных терминалах:
https://en.wikipedia.org/wiki/ANSI_escape_code#Colors

закрытие как фиксированное выше по потоку