Ipython: Permitir referências a variáveis ​​Python em células Markdown

então ,, isso está morto? Seria ótimo como o tópico anterior apontou? Desculpe se eu gostaria de ter o skilz para implementar (eu não), mas tenho certeza que usaria ...

Não está morto, só preciso fazer algumas coisas primeiro.

Eu perguntei sobre isso no SO , apenas para descobrir que era uma duplicata dupla daqui e daqui .

Meu 2c seria aquele

• A sintaxe Jinja seria ótima
• Parece, de uma olhada rápida, que o markdown não tem realmente um 'puro' , mas se todas as convenções de formatação de uma implementação bem estabelecida (: octocat: github seria uma boa) fossem seguidas, então adicionar um método de injeção não é na verdade, um problema de remarcação.
• os erros podem ser configuráveis ​​pelo usuário? Uma opção de [invisível (nada acontece), a palavra error ou um grande rastreamento de pilha sujo]
• Contanto que seja uma resposta de texto, ela poderia ser injetada antes de ser passada para o renderizador de redução, para que pudesse injetar html ou ainda mais redução!

Não para defender qualquer sintaxe particular (acho que {{}} está bem), mas aqui está o design comparável para R: http://www.rstudio.com/ide/docs/authoring/using_markdown (Eles usam `` `como o delimitador )

Lunamark usa

: +1:

: +1 :, este seria um recurso muito útil!

Seria muito bom ter a mesma sintaxe de http://blog.rstudio.org/2014/06/18/r-markdown-v2/

Não sei, usando os delimitadores de estilo R, ou seja, crases simples e triplos, respectivamente, parece que não poderíamos escolher entre apenas exibir o código (como some code snippet/example ) e _avaliar_ código e exibir o resultado ( por exemplo, my_var ) - Não acho isso muito prático (se entendi bem).

O caso de uso é escrever prosa de caderno com valores computados incorporados, como "_O desemprego médio para Morgan County em 2014 foi de 8,4%, abaixo de 10,3% em 2009._" Neste exemplo, você pode imaginar as porcentagens e anos sendo calculados a partir de dados.

O caso de uso mais amplo é "documentos inteligentes", onde você tem texto e gráficos automaticamente (re) gerados (talvez ocultando o código para legibilidade) dos dados.

Acho que é um recurso útil.

Eu realmente gosto do modelo "knitr" em rstudio (um documento markdown, blocos de código são interpretados, valores estão disponíveis em markdown -> é convertido em PDF / html / ... que posso publicar como um artigo de jornal. Diferente de um caderno já que o notebook é baseado em várias células e não tenho certeza de como influenciar se a saída é exibida ou não).

Não me importo como os valores são incluídos no texto, mas eu acharia bom se R (com knitr / rstudio) e ipython usassem o mesmo.

Ou algo semelhante a ruby ​​ou bash, onde # {varname ou declaração} pode ser
misturado dentro da corda.

1. junho de 2014 20:27 skrev "Jan Schulz" [email protected] følgende:

Eu realmente gosto do modelo "knitr" em rstudio (um documento de marcação, código
blocos são interpretados, os valores estão disponíveis na redução -> é convertido
em PDF / html / ... que posso publicar como um artigo de jornal. Diferente de um
notebook, pois o notebook é baseado em várias células e não tenho certeza de como
influência se a saída é mostrada ou não).

Não me importo como os valores estão incluídos no texto, mas eu iria encontrar
bom se R (com knitr / rstudio) e ipython usassem o mesmo.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment -46875435.

Eu percebo o caso de uso de código interpretado, é claro, estou apenas preocupado com a possibilidade de perdermos a capacidade do markdown de "apenas" exibir o código (sem interpretá-lo / avaliá-lo), like this , se a sintaxe R (ou seja, crases ) foram escolhidos.

Acho que no markdown do knitr / R você pode indicar se deseja exibir o código (devidamente destacado, etc) ou apenas a saída (gráficos, tabelas, ...).

Eu tenho formação em economia e não quero ver nenhum código em meus papéis, então isso é um pouco diferente do (na minha opinião) caso de uso otimizado de exibir código.

@bilderbuchi oh, desculpe, interpretei mal o contexto do seu comentário "não acho que isso seja útil".

E eu concordo: o que quer que seja implementado não deve quebrar o markdown existente.

Isso seria maravilhoso e faria IPython comer o almoço de knitr.

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

Eu realmente gosto dessa abordagem: pega uma célula e pré-processa para uma redução válida, então nenhuma mudança no processador de redução é necessária.

muito bom ... vou usar em breve

No domingo, 17 de agosto de 2014 às 14h18, Jan Schulz [email protected]
escreveu:

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

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment -52431760.

Tom Brander
http://tombrander.com -Real Estate
http://oswco.com -Open Software
3763 West Jackson Blvd.
Birmingham, AL 35213
Telefone 205-267-1089
@dartdog

: +1: elegante. Vou usar também.

@JanSchulz , obrigado! Estou realmente ansioso para experimentar o python-markdown.

Existe alguma chance de colocar isso no ipython principal ( jupyter )?

Existe alguma chance de obter isso no ipython principal (jupyter)?

Provavelmente não em breve. Precisamos fazer muito design em segundo plano para que isso funcione.
Em especial, precisaríamos de uma maneira oficial de estender a sintaxe de markdown em vez de apenas inventar uma nova.

Na verdade, isso (e também o knitr / rmarkdown AFAIK) funciona com uma conversão de dois estágios: primeiro, a substituição de quaisquer codeblocks pela saída do código e, em seguida, converta o resto como markdown padrão. Portanto, esta não é uma extensão do markdown, mas um pré-processador para uma célula.

Acho que a questão difícil é como lidar com código Python invisível arbitrário que é executado de dentro de uma célula de marcação. Não acho que a execução do código possa ser restringida em uma implementação útil.

Contanto que seja uma extensão separada que você precisa instalar e ativar ativamente, este é um assunto diferente. Além disso, o código Python só é executado se o notebook for confiável.

Pretendo adicionar uma dica de ferramenta mostrando o código-fonte se você passar o mouse sobre a saída do código Python em uma célula de marcação, para que você possa ver de onde veio isso.

Na verdade, isso (e também o knitr / rmarkdown AFAIK) funciona com uma conversão de dois estágios: primeiro, a substituição de quaisquer codeblocks pela saída do código e, em seguida, converta o resto como markdown padrão. Portanto, esta não é uma extensão do markdown, mas um pré-processador para uma célula.

Qual é a marcação personalizada. Isso já é o que temos com o mathjax. Obviamente, temos que armazenar o
remarcação de pré-processamento no caso de você reexecutar o notebook, portanto, qualquer ferramenta que queira usar nossa marcação terá que lidar com o pré-processamento personalizado.
Pré ou pós-processador, inventamos nossa própria sintaxe, que pode ou não entrar em conflito com o que as pessoas querem ou farão mais tarde.

Acho que a questão difícil é como lidar com código Python invisível arbitrário que é executado de dentro de uma célula de marcação. Não acho que a execução do código possa ser restringida em uma implementação útil.

Contanto que seja uma extensão separada que você precisa instalar e ativar ativamente, este é um assunto diferente. Além disso, o código Python só é executado se o notebook for confiável.

Pretendo adicionar uma dica de ferramenta mostrando o código-fonte se você passar o mouse sobre a saída do código Python em uma célula de marcação, para que você possa ver de onde veio isso.

Se fizermos isso, poderemos restringir a user_variable, ou seja, retornar o valor da chave user_ns . Isso deve impedir a maior parte da execução.

Se fizermos isso, poderemos restringir a user_variable, ou seja, retornar o valor da chave user_ns. Isso deve impedir a maior parte da execução.

Você também vai querer permitir funções de chamada. Um caso trivial seria formatar a saída ou chamar um _repr_ personalizado.

Eu adoraria ver algo assim implementado. Parece que a solução mais direta é executar células MD por meio de um filtro Jinja. Isso já foi feito antes. Veja dexi , por exemplo.

Por outro lado, não acho que isso deva ser habilitado por padrão em todas as células. Jinja aumentaria a complexidade da marcação consideravelmente e Jinja + Markdown provavelmente deveria usar um modo de realce diferente do MD simples. Por que não implementar isso como um tipo de célula separado?

Acho que esse problema poderia desaparecer, se fosse possível a partir do código ocultar / substituir a célula de código semelhante ao que é feito para o markdown atualmente:

-> Adicione uma %%pymarkdown magic, que produz uma mensagem text/markdown e indica que a fonte deve ser invisível / substituída pela saída. A mágica então simplesmente faria um s & r na entrada.

[Editar: Ok, tem problemas diferentes, como nenhum destaque de sintaxe e não faz sentido no qtconsole ...]

Relevante: o Mathematica 10 adicionou suporte para "relatórios", consulte: http://www.wolfram.com/mathematica/new-in-10/automated-report-generation/

Eu (ainda) não brinquei com isso em detalhes, mas parece que você pode usar o notebook como modelo, incorporando referências a variáveis ​​e saída computada no texto do notebook.

Suponha que temos várias referências em várias células MD para a mesma variável. Quais células devem ser renderizadas novamente quando ele muda seu valor?

@Pipeliner Não tenho certeza de onde você quer chegar. Em notebooks iPython / Jupyter, cada célula deve ser explicitamente renderizada (por meio de Ctrl-return de dentro da célula ou de Célula-> Executar tudo na barra de menus). Que eu saiba, não há detecção automática de dados desatualizados. Você está pensando em knitr / rmarkdown? knitr / rmarkdown tenta manter um cache de resultados de cada célula e os marca como sujos quando as células anteriores mudam.

existem soluções alternativas para este problema que as pessoas estão usando ?. Eu amo notebooks ipython / jupyter, mas seria incrível se pudéssemos apenas fazer a {{variável python}} na marcação. É muito útil se você estiver preparando um notebook com um pequeno conjunto de dados de amostra e depois quiser trocar o conjunto completo e ter tudo atualizado

Você pode usar um widget PlaceProxy para renderizar um widget em qualquer seletor html na página. Em sua redução, incorpore <span id="myid">placeholder</span> e, posteriormente, em seu código, use algo como x=HTML('widget value'), PlaceProxy(child=x, selector='#myid') . Então, sempre que você definir x.value='something' , a atualização será refletida no widget que é exibido na redução. Consulte https://github.com/ipython/ipywidgets/blob/1e407cef864363c66a23781b8d560a6ac18b3370/ipywidgets/widgets/widget_box.py#L70 para a definição de PlaceProxy.

Muitas advertências, é claro. se você editar o markdown, o widget desaparecerá. Se você abrir o bloco de notas, o widget pode não ter sido criado, por isso não será exibido etc. Mas ele permite que você controle programaticamente uma saída dentro de uma célula de redução.

Outra opção é construir a string e exibir a redução como uma saída, não como uma célula de redução. Ele não será atualizado dinamicamente, mas toda vez que você avaliar a célula, o markdown será atualizado.

Você pode tentar estas extensões de notebook:
https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/python-markdown_v3

Eu não queria construir a string e colocá-la como saída, pois fica muito confuso ter grandes strings html - uma ideia legal, eu nem pensei nisso. Mas há definitivamente algumas boas soluções que resolvem o problema - obrigado!

Eu acho que esse recurso é muito importante para alguém que vem do Rmarkdown. R fez um trabalho muito melhor ao criar bons relatórios.

Eu vi uma duplicata deste problema no notebook. Isso já é possível usando IPython.display.Markdown em uma célula de código:

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

Agradável! Também seria fácil escrever um utilitário (ou até mesmo uma mágica de redução de %%)
que puxa automaticamente as variáveis ​​do namespace dos kernels, para que você possa
Faz:

%%markdown

## Subsection

Here is {one} and {two}

Na quarta-feira, 26 de abril de 2017 às 18:35, Grant Nestor [email protected]
escreveu:

Eu vi uma duplicata deste problema no notebook. Isso já é possível
usando IPython.display.Markdown em uma célula de código:

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

from IPython.display import Markdown

um = 1
dois = 2
três = um + dois

Markdown ("# Título")
Markdown ("" "# Matemática ## AdiçãoAqui está um exemplo de adição simples: {um} + {dois} = {três}" "". Formato (um = um, dois = dois, três = três))

-
Você está recebendo isso porque foi designado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-297586914 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AABr0CIHhxwNwQF6MiHHy2M612zRnf5Wks5rz_D4gaJpZM4AchzX
.

-
Brian E. Granger
Professor Associado de Física e Ciência de Dados
Universidade Estadual Cal Poly, San Luis Obispo
@ellisonbg no Twitter e GitHub
[email protected] e [email protected]

@ellisonbg Isso seria bom e eu acho que esta é a maneira certa de fazer isso (renderizar a marcação do Python vs. estender a marcação e outras máquinas de marcação de maneiras que talvez não devam ser estendidas). @Carreau Tem interesse em algo assim?

Além disso, combinando isso com o novo recurso de tags de célula no notebook (consulte a postagem de lançamento do nbconvert-hide tag). @takluyver A nbconvert-hide atualmente funciona com nbconvert?

Eu não acho que ainda, mas acho que devemos adicionar algumas tags nbconvert.

+1 para tudo isso! Além disso, estamos atualmente trabalhando para ocultar entradas / saídas em
JupyterLab e será capaz de persistir esse estado para o nbconvert
metadados.

Em quinta-feira, 27 de abril de 2017 às 7h33, Grant Nestor [email protected]
escreveu:

@ellisonbg https://github.com/ellisonbg Isso seria bom e eu acho
esta é a maneira certa de fazer isso (renderizando a marcação do Python vs.
estendendo marcados e outros maquinários de marcação de forma que talvez
não deve ser estendido). @Carreau https://github.com/Carreau Qualquer
interesse em algo assim?

Além disso, combinando isso com o novo recurso de tags de célula no notebook
(veja a postagem de lançamento do notebook 5.0
http://blog.jupyter.org/2017/04/04/jupyter-notebook-5-0/ ), você deve
ser capaz de esconder células de entrada ao converter um notebook usando nbconvert
(por exemplo, usando a tag nbconvert-hide). @takluyver https://github.com/takluyver
A tag nbconvert-hide funciona atualmente com nbconvert?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-297731409 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AABr0BNgLTtlzwbrIjqBquzsE9lhLXchks5r0KdAgaJpZM4AchzX
.

-
Brian E. Granger
Professor Associado de Física e Ciência de Dados
Universidade Estadual Cal Poly, San Luis Obispo
@ellisonbg no Twitter e GitHub
[email protected] e [email protected]

@Carreau Tem interesse em algo assim?

Esta forma de fazer as coisas já foi discutida em 2013 e a AFAICT foi desaprovada como:

• você precisa reimplementar %% markdown em todos os idiomas
• requer computação no lado do kernel para exibir texto
• ele muda o significado semântico de renderizar uma redução.
• errar nbconvert --to markdown e nbconvert --to script
• notebooks bagunçados importam ganchos.

Isso está quebrando a semântica do notebook (IMHO), porque então o texto das células "markdown" depende do estado do kernel. Então, embora seja fofo, vou rejeitar essa ideia.

Além disso, a magia %%markdown , %%latex , %%javascript ... etc foi escrita no momento em que estávamos tendo esta discussão.

Notarei que mágicas semelhantes existem há bastante tempo e recursos muito mais avançados do que apenas usar %%markdown , então, por favor, não se apresse porque você saiu como nunca teve essa ideia antes.

Meu pensamento evoluiu com o tempo e gosto da ideia de @gnestor .

Por definição, se um usuário deseja variáveis ​​do kernel na célula de redução,
essa célula de redução dependerá do kernel. Dizendo "isso quebra o
semântica do notebok "é como dizer que não devemos permitir células de código
porque eles são executados no kernel e retornam a saída. Um dos principais propósitos
do documento do caderno serve como um registro do que o kernel faz.
A implementação em qualquer kernel que suporte uma saída rica é trivial e
isso quebra qualquer coisa downstream (nbconvert, import hooks), então essas coisas
tem bugs (saída de markdown já é uma coisa).

Mas estou bem fazendo isso fora do kernel ipython ...

Na quinta-feira, 27 de abril de 2017 às 10:29, Matthias Bussonnier <
notificaçõ[email protected]> escreveu:

@Carreau https://github.com/Carreau Tem interesse em algo assim?

Essa forma de fazer já foi discutida em 2013 algo e
AFAICT foi desaprovada como:

• você precisa reimplementar %% markdown em todos os idiomas
• requer computação no lado do kernel para exibir texto
• ele muda o significado semântico de renderizar uma redução.
• estragar nbconvert --para markdown e nbconvert --para script
• notebooks bagunçados importam ganchos.

Isso está quebrando a semântica do notebook (IMHO), porque então o texto de
as células de "redução" dependem do estado do kernel. Então, enquanto for fofo, eu vou
para votar contra essa ideia.

Além disso, a mágica %% markdown, %% latex, %% javascript ... etc foi escrita em
o momento em que estávamos tendo essa discussão.

Vou notar que magias semelhantes já existem há algum tempo
https://gist.github.com/bj0/5343292 e recursos muito mais avançados do que
apenas usando %% markdown, então por favor não se apresse porque você saiu como
você nunca encontrou essa ideia antes.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-297784026 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AABr0HU-Gb3ENSidykbte53geYqPpy-sks5r0NCAgaJpZM4AchzX
.

-
Brian E. Granger
Professor Associado de Física e Ciência de Dados
Universidade Estadual Cal Poly, San Luis Obispo
@ellisonbg no Twitter e GitHub
[email protected] e [email protected]

Implementação de referência (extensão de notebook clássica): https://github.com/ipython-contrib/jupyter_contrib_nbextensions/blob/master/src/jupyter_contrib_nbextensions/nbextensions/python-markdown/main.js

Eu acho que esta é a maneira certa de fazer isso (renderizando a marcação do Python

Apenas esclarecendo, já que inicialmente li sua declaração errada - isso é usar o kernel para exibir markdown (como um tipo MIME de markdown), não para renderizar markdown em html. A marcação de renderização real para html ainda está sendo feita no lado do cliente, no nbconvert, etc.

Eu gosto dessa abordagem. Se você deseja uma redução fácil que envolve o estado do kernel, use o kernel para exibir essa redução. Se você deseja que o markdown seja atualizado ao vivo, use um widget (você poderia usar um OutputWidget, ou podemos fazer um MarkdownWidget semelhante ao HTMLWidget). Isso, acompanhado de maneiras fáceis de ocultar / mostrar entrada e saída, faz muito sentido para mim.

Acabei de encontrar este tíquete e gostaria de mencionar que o SoS também adotou a abordagem mencionada anteriormente, ou seja, renderizar a marcação a partir do kernel. Basicamente, o sos implementa uma magia %render que renderiza o stdout de uma célula em MD (por padrão), HTML etc, e como o sos suporta diferentes linguagens, ele também renderiza a saída de qualquer subkernel que inicia.

Aqui está uma solução simples: https://github.com/jupyter/nbconvert/issues/320

Seria bom se aconteça o que acontecer também pode ser compatível com RMarkdown. Que usa

 O valor de x é `rx`.

Onde x é uma variável em R.

https://github.com/vatlab/markdown-kernel não é necessariamente o que você precisa, mas suporta células Rmarkdown em um ambiente Jupyter.

TL; DR: este tópico ainda está atualizado? O JupyterLab não tem solução direta, mas o Notebook tem? (2020)

Então ... lendo este tópico e tentando os vários hacks sugeridos ... parece que em 2020 esse recurso ainda é impossível / ausente no JupyterLab (que o site principal tem pressionado as pessoas a usarem há vários anos?), a menos que você use SoS (todas as outras soluções alternativas parecem ser apenas notebooks, ou seja, legado / inútil para instalações modernas ... ou requeiram o descarte da maior parte da conveniência de usar a funcionalidade principal "code + markdown" do Jupyter).

Há algo que eu perdi? Parece que o JupyterLab principal (nota: não Notebooks, que funcionam bem, e me sinto um pouco traído pelo fato de o projeto principal pressionar tanto o Lab quando Notebooks claramente funcionam muito melhor, mesmo agora em 2020) essencialmente não suporta remarcação em documentos para qualquer coisa além do trivial, não-análise, exemplos - retoricamente falando: qual é o ponto de incluir um sistema de formatação em um produto de análise de dados se você não pode produzir seus dados com a formatação?

Isso parece tão errado que acho que devo ter esquecido algo básico. "SoS + markdown-kernel" parece uma marreta para quebrar uma noz, mas como funciona ...