Ipython: Разрешить ссылки на переменные Python в ячейках Markdown

так, это мертв? Было бы здорово, как указала предыдущая ветка? Извините, что натолкнулся, если бы у меня не было навыков для реализации (я не знаю), но я уверен, что использовал бы ...

Не умер, просто нужно сначала сделать несколько вещей.

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

Мой 2с был бы таким

• Синтаксис Jinja был бы отличным
• На первый взгляд кажется, что у markdown действительно нет ``
• Могут ли ошибки быть настраиваемыми пользователем? Вариант [невидимый (ничего не происходит), слово error или грязная трассировка большого стека]
• Пока это текстовый ответ, он может быть введен до того, как он будет передан модулю рендеринга уценки, чтобы он мог внедрить html или даже больше уценки!

Не защищать какой-либо конкретный синтаксис (я думаю, что {{}} это нормально), но вот сопоставимый дизайн для R: http://www.rstudio.com/ide/docs/authoring/using_markdown (они используют `` в качестве разделителя ).

Лунамарк использует

: +1:

: +1:, это была бы очень полезная функция!

Было бы неплохо иметь такой же синтаксис, как http://blog.rstudio.org/2014/06/18/r-markdown-v2/

Я не знаю, используя разделители в стиле R, то есть одиночные и тройные обратные кавычки, соответственно, кажется, что мы не могли выбрать между простым отображением кода (например, some code snippet/example ) и _evaluating_ кода и отображением результата ( например, my_var ) - я не думаю, что это очень практично (если я правильно понимаю).

Пример использования - написание записной книжки со встроенными вычисленными значениями, такими как «_Средний уровень безработицы в округе Морган в 2014 году составлял 8,4% по сравнению с 10,3% в 2009 году_». данные.

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

Думаю, это полезная функция.

Мне очень нравится модель «knitr» в rstudio (один документ уценки, блоки кода интерпретируются, значения доступны в уценке -> конвертируются в PDF / html / ... который я могу опубликовать как журнальную статью. В отличие от записной книжки поскольку блокнот основан на нескольких ячейках, и я не уверен, как повлиять на отображение вывода или нет).

Я не возражаю против включения значений в текст, но мне было бы неплохо, если бы и R (с knitr / rstudio), и ipython использовали бы то же самое.

Или что-то похожее на ruby ​​или bash, где # {varname or statement} может быть
смешанный внутри строки.

1. июнь 2014 20:27 skrev "Ян Шульц" [email protected] følgende:

Мне очень нравится модель "knitr" в rstudio (один документ уценки, код
блоки интерпретируются, значения доступны в уценке -> преобразуется
в PDF / html / ... который я могу опубликовать как журнальную статью. В отличие от
блокнот, поскольку блокнот основан на нескольких ячейках, и я не знаю, как
влияет на отображение вывода или нет).

Я не против, как значения включены в текст, но я бы это нашел
хорошо, если бы и R (с knitr / rstudio), и ipython использовали бы одно и то же.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment -46875435.

Я, конечно, понимаю вариант использования интерпретируемого кода, меня просто беспокоит, что мы потеряем способность markdown «просто» отображать код (без его интерпретации / оценки), like this , если синтаксис R (т.е. обратные кавычки) ) были выбраны.

Я думаю, что в knitr / R markdown вы можете указать, хотите ли вы отображать код (правильно выделенный и т. Д.) Или только вывод (графики, таблицы, ...).

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

@bilderbuchi извините, я неверно истолковал контекст вашего комментария «не думаю, что это полезно».

И я согласен: все, что реализовано, не должно нарушать существующую уценку.

Это было бы замечательно и заставило бы IPython съесть обед вязальщицы.

https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/python-markdown

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

очень хорошо ... скоро воспользуюсь

В воскресенье, 17 августа 2014 г., в 14:18, Ян Шульц [email protected]
написал:

https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/python-markdown

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment -52431760.

Том Брандер
http://tombrander.com -Real Estate
http://oswco.com - открытое программное обеспечение
3763 West Jackson Blvd.
Бирмингем, AL 35213
Телефон 205-267-1089
@dartdog

: +1: элегантно. Я тоже буду использовать.

@JanSchulz , спасибо! Я действительно с нетерпением жду возможности попробовать python-markdown.

Есть ли шанс поместить это в основной ipython ( jupyter )?

Есть ли шанс попасть в основной ipython (jupyter)?

Наверное, не скоро. Чтобы это работало, нам нужно много работать над дизайном в фоновом режиме.
В частности, нам понадобится официальный способ расширения синтаксиса уценки вместо того, чтобы просто изобретать новый.

На самом деле это (а также knitr / rmarkdown AFAIK) работает за счет двухэтапного преобразования: сначала замена любых кодовых блоков на вывод кода, а затем преобразование остальных в стандартную уценку. Так что это не расширение уценки, а препроцессор для ячейки.

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

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

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

На самом деле это (а также knitr / rmarkdown AFAIK) работает за счет двухэтапного преобразования: сначала замена любых кодовых блоков на вывод кода, а затем преобразование остальных в стандартную уценку. Так что это не расширение уценки, а препроцессор для ячейки.

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

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

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

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

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

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

Вы также захотите разрешить вызов функций. Тривиальным случаем было бы форматирование вывода или вызов пользовательского _repr_.

Я бы хотел, чтобы что-то подобное было реализовано. Похоже, что наиболее простое решение - пропустить ячейки MD через фильтр Jinja. Это было сделано раньше. См., Например, dexi .

С другой стороны, я не думаю, что это должно быть включено по умолчанию во всех ячейках. Jinja значительно усложнит разметку, и Jinja + Markdown, вероятно, должен использовать другой режим выделения, чем обычный MD. Почему бы не реализовать это как отдельный тип ячеек?

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

-> Добавить магию %%pymarkdown , которая выводит сообщение text/markdown и указывает, что источник должен быть невидим / заменен выводом. Затем магия просто выполнит s & r во входных данных.

[Edit: Хорошо, у него разные проблемы, такие как отсутствие подсветки синтаксиса и отсутствие смысла в qtconsole ...]

Релевантно: в Mathematica 10 добавлена ​​поддержка «отчетов», см .: http://www.wolfram.com/mathematica/new-in-10/automated-report-generation/

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

Предположим, у нас есть несколько ссылок в нескольких ячейках MD на одну и ту же переменную. Какие ячейки должны отображаться снова при изменении своего значения?

@Pipeliner Я не клоните . В записных книжках iPython / Jupyter каждая ячейка должна быть явно отображена (либо с помощью Ctrl-возврата внутри ячейки, либо с помощью Ячейки-> Выполнить все в строке меню). Мне известно об автоматическом обнаружении устаревших данных. Вы думаете о вязальщике / разметке? knitr / rmarkdown пытается поддерживать кеш результатов из каждой ячейки и отмечает их как грязные при изменении более ранних ячеек.

Есть ли какие-либо обходные пути для этой проблемы, которые используют люди? Мне нравятся записные книжки ipython / jupyter, но было бы замечательно, если бы мы могли просто указать {{переменную python}} в разметке. Это так удобно, если вы готовите записную книжку с небольшими примерами наборов данных, а затем хотите поменять местами полный набор и все обновить.

Вы можете использовать виджет PlaceProxy для рендеринга виджета в любом селекторе html на странице. В уценку вставьте <span id="myid">placeholder</span> , а затем в код используйте что-то вроде x=HTML('widget value'), PlaceProxy(child=x, selector='#myid') . Затем каждый раз, когда вы устанавливаете x.value='something' , обновление отражается в виджете, который отображается в разметке. См. Https://github.com/ipython/ipywidgets/blob/1e407cef864363c66a23781b8d560a6ac18b3370/ipywidgets/widgets/widget_box.py#L70 для определения PlaceProxy.

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

Другой вариант - построить строку и отобразить уценку как результат, а не как ячейку уценки. Он не будет обновляться динамически, но каждый раз, когда вы оцениваете ячейку, уценка будет обновляться.

Вы можете попробовать эти расширения для записных книжек:
https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/python-markdown_v3

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

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

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

from IPython.display import Markdown

one = 1
two = 2
three = one + two

Markdown("# Title")
Markdown("""
# Math
## Addition
Here is a simple addition example: {one} + {two} = {three}
""".format(one=one, two=two, three=three))

Отлично! Также было бы легко написать утилиту (или даже магию уценки %%)
которые автоматически извлекают переменные из пространства имен ядер, чтобы вы могли
делать:

%%markdown

## Subsection

Here is {one} and {two}

В среду, 26 апреля 2017 г., в 18:35, Грант Нестор [email protected]
написал:

Я видел дубликат этой проблемы в записной книжке. Это уже возможно
используя IPython.display.Markdown в ячейке кода:

[image: image]
https://cloud.githubusercontent.com/assets/512354/25464012/f434c52c-2aae-11e7-9171-541fb0f6601e.png

из IPython.display import Markdown

один = 1
два = 2
три = один + два

Уценка ("# Заголовок")
Markdown ("" "# Math ## Addition Вот простой пример сложения: {one} + {two} = {three}" "". Format (one = one, two = two, three = three))

-
Вы получаете это, потому что вас назначили.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-297586914 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AABr0CIHhxwNwQF6MiHHy2M612zRnf5Wks5rz_D4gaJpZM4AchzX
.

-
Брайан Э. Грейнджер
Доцент кафедры физики и данных
Государственный университет Калифорнийского Поли, Сан-Луис-Обиспо
@ellisonbg в Твиттере и на GitHub
[email protected] и [email protected]

@ellisonbg Это было бы неплохо, и я думаю, что это правильный способ сделать это (рендеринг уценки из Python против расширения отмеченного и других механизмов уценки таким образом, что его, возможно, не следует расширять). @Carreau Есть интерес к чему-то вроде этого?

Кроме того, объединив это с новой функцией тегов ячеек в записной книжке (см. Сообщение о выпуске записной книжки 5.0 ), вы сможете скрыть ячейки ввода при преобразовании записной книжки с помощью nbconvert (например, с помощью тега nbconvert-hide ). @takluyver Работает ли nbconvert-hide настоящее время с nbconvert?

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

+1 ко всему этому! Кроме того, в настоящее время мы работаем над скрытием входов / выходов в
JupyterLab и сможет сохранить это состояние в nbconvert
метаданные.

27 апреля 2017 г., в 7:33, Грант Нестор [email protected]
написал:

@ellisonbg https://github.com/ellisonbg Это было бы неплохо, и я думаю
это правильный способ сделать это (разметка рендеринга из Python vs.
расширение маркированного и другого оборудования для уценки таким образом, чтобы
не следует продлевать). @Carreau https://github.com/Carreau Любой
интерес в чем-то подобном?

Кроме того, в сочетании с новой функцией тегов ячеек в блокноте
(см. сообщение о выпуске ноутбука 5.0
http://blog.jupyter.org/2017/04/04/jupyter-notebook-5-0/ ) вам следует
иметь возможность скрывать ячейки ввода при преобразовании записной книжки с помощью nbconvert
(например, используя тег nbconvert-hide). @takluyver https://github.com/takluyver
Тег nbconvert-hide в настоящее время работает с nbconvert?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-297731409 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AABr0BNgLTtlzwbrIjqBquzsE9lhLXchks5r0KdAgaJpZM4AchzX
.

-
Брайан Э. Грейнджер
Доцент кафедры физики и данных
Государственный университет Калифорнийского Поли, Сан-Луис-Обиспо
@ellisonbg в Твиттере и на GitHub
[email protected] и [email protected]

@Carreau Есть интерес к чему-то вроде этого?

Этот способ ведения дел уже обсуждался в 2013 году, и AFAICT не одобрили:

• вам нужно повторно реализовать %% уценку на всех языках
• для отображения текста требуется вычисление на стороне ядра
• он изменяет семантическое значение рендеринга уценки.
• облажался nbconvert --to markdown и nbconvert --to script
• завинчивающиеся записные книжки импортные крючки.

Это нарушает семантику ноутбука (ИМХО), потому что тогда текст ячеек «уценки» зависит от состояния ядра. Так что, хотя это мило, я собираюсь проголосовать против этой идеи.

Также во время этого обсуждения были написаны магия %%markdown , %%latex , %%javascript ... и т. Д.

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

Мое мышление изменилось со временем, и мне нравится идея

По определению, если пользователю нужны переменные из ядра в ячейке уценки,
эта ячейка уценки будет зависеть от ядра. Сказать "это нарушает
семантика блокнота "подобна заявлению, что мы не должны разрешать ячейки кода
потому что они работают в ядре и возвращают результат. Одна из основных целей
документа записной книжки служит записью того, что делает ядро.
Реализация в любом ядре, поддерживающем расширенный вывод, тривиальна, и она
это сломает что-либо ниже по течению (nbconvert, import hooks), затем эти вещи
есть ошибки (вывод уценки уже есть).

Но я нормально делаю это вне ядра ipython ...

В четверг, 27 апреля 2017 г., в 10:29, Маттиас Бюссонье <
[email protected]> написал:

@Carreau https://github.com/Carreau Есть интерес к чему-то вроде этого?

Такой способ ведения дел уже обсуждался в 2013 году, и
AFAICT не одобрили:

• вам нужно повторно реализовать %% уценку на всех языках
• для отображения текста требуется вычисление на стороне ядра
• он изменяет семантическое значение рендеринга уценки.
• облажаться nbconvert --to markdown и nbconvert --to script
• завинчивающиеся записные книжки импортные крючки.

Это нарушает семантику записной книжки (ИМХО), потому что тогда текст
количество ячеек "уценки" зависит от состояния ядра. Так что пока это мило, я иду
проголосовать против этой идеи.

Также магия %% markdown, %% latex, %% javascript ... и т. Д. Была написана в
время, когда мы обсуждали это.

Замечу, что подобные магии существуют уже довольно давно.
https://gist.github.com/bj0/5343292 и более продвинутые функции, чем
просто используя %% markdown, поэтому, пожалуйста, не торопитесь, потому что вы вышли как
вы никогда раньше не сталкивались с этой идеей.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-297784026 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AABr0HU-Gb3ENSidykbte53geYqPpy-sks5r0NCAgaJpZM4AchzX
.

-
Брайан Э. Грейнджер
Доцент кафедры физики и данных
Государственный университет Калифорнийского Поли, Сан-Луис-Обиспо
@ellisonbg в Твиттере и на GitHub
[email protected] и [email protected]

Эталонная реализация (расширение классического блокнота): https://github.com/ipython-contrib/jupyter_contrib_nbextensions/blob/master/src/jupyter_contrib_nbextensions/nbextensions/python-markdown/main.js

Я думаю, что это правильный способ сделать это (разметка рендеринга из Python

Просто уточнить, поскольку я изначально неправильно прочитал ваше утверждение - это использует ядро ​​для отображения уценки (как mimetype уценки), а не для рендеринга уценки в html. Фактическая уценка рендеринга до HTML все еще выполняется на стороне клиента, в nbconvert и т. Д.

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

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

Вот простое исправление: https://github.com/jupyter/nbconvert/issues/320

Было бы неплохо, если бы все, что происходит, также было совместимо с RMarkdown. Это использует

 Значение x равно «rx».

Где x - переменная в R.

https://github.com/vatlab/markdown-kernel не обязательно то, что вам нужно, но он поддерживает ячейки Rmarkdown в среде Jupyter.

TL; DR: эта ветка все еще актуальна? У JupyterLab нет прямого решения, а у Notebook есть? (2020)

Итак ... читая эту ветку и пробуя различные предлагаемые хаки ... кажется, что с 2020 года эта функция все еще невозможна / отсутствует в JupyterLab (который основной сайт подталкивает людей использовать уже несколько лет?), если вы не используете SoS (все остальные обходные пути кажутся либо только для ноутбуков, то есть устаревшими / бесполезными для современных установок ... или требуют отказа от большей части удобства использования основных функций Jupyter «код + уценка»).

Я что-то пропустил? Похоже, что основной JupyterLab (примечание: не ноутбуки, которые работают нормально, и я чувствую себя немного обманутым тем, что основной проект так сильно подталкивает Lab, когда ноутбуки явно работают намного лучше, даже сейчас в 2020 году) по существу не поддерживает уценку в документы для чего-либо, кроме тривиальных, не связанных с анализом, примеров - говоря риторически: какой смысл включать систему форматирования в продукт для анализа данных, если вы не можете вывести свои данные с форматированием?

Это кажется настолько неправильным, что я, должно быть, упустил что-то базовое. "SoS + markdown-kernel" похоже на кувалду, чтобы расколоть грецкий орех, но поскольку это работает ...