Ipython: Permitir referencias a variables de Python en celdas de Markdown

entonces, ¿está esto muerto? ¿Sería genial como señaló el hilo anterior? Lamento chocar desearía tener la habilidad para implementar (no lo hago) pero seguro que usaría ...

No muerto, solo necesito hacer algunas cosas primero.

Solo pregunté sobre esto en SO , solo para descubrir que era un duplicado doble de aquí y aquí .

Mi 2c sería eso

• La sintaxis de Jinja sería genial
• De un vistazo rápido, parece que Markdown realmente no tiene un 'puro' , pero si se siguieron todas las convenciones de formato de una implementación bien establecida (: octocat: github sería una buena), entonces agregar un método de inyección no lo es en realidad, un problema de rebajas.
• ¿Podrían los errores ser algo configurable por el usuario? Una opción de [invisible (no pasa nada), la palabra error , o un rastro de pila grande sucio]
• Siempre que sea una respuesta de texto, podría inyectarse antes de pasar al renderizador de rebajas, por lo que podría inyectar html o incluso más rebajas.

No es para defender ninguna sintaxis en particular (creo que {{}} está bien), pero aquí hay un diseño comparable para R: http://www.rstudio.com/ide/docs/authoring/using_markdown (usan "" como delimitador ).

Usos de Lunamark

: +1:

: +1 :, ¡esta sería una característica muy útil!

Sería muy bueno tener la misma sintaxis que http://blog.rstudio.org/2014/06/18/r-markdown-v2/

No sé, usando los delimitadores de estilo R, es decir, comillas inversas simples y triples, respectivamente, parece que no podríamos elegir entre mostrar el código (como some code snippet/example ) y _evaluar_ el código y mostrar el resultado ( eg my_var ) - No creo que esto sea muy práctico (si lo entiendo correctamente).

El caso de uso es escribir prosa de cuaderno con valores computados incrustados, como "_El desempleo promedio para el condado de Morgan en 2014 fue del 8,4%, frente al 10,3% en 2009._" En este ejemplo, podría imaginarse los porcentajes y años calculados a partir de datos.

El caso de uso más amplio es el de los "documentos inteligentes", en los que el texto y los gráficos se (re) generan automáticamente (quizás ocultando el código para facilitar la lectura) de los datos.

Creo que es una característica útil.

Realmente me gusta el modelo "knitr" en rstudio (un documento de rebaja, los bloques de código se interpretan, los valores están disponibles en rebaja -> se convierte en PDF / html / ... que puedo publicar como un artículo de revista. Diferente a un cuaderno ya que el portátil se basa en varias celdas y no estoy seguro de cómo influir en si se muestra o no la salida).

No me importa cómo se incluyen los valores en el texto, pero me gustaría que tanto R (con knitr / rstudio) como ipython usaran lo mismo.

O algo similar a ruby ​​o bash, donde # {varname or statement} puede ser
mezclado dentro de la cuerda.

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

Realmente me gusta el modelo "knitr" en rstudio (un documento de rebajas, código
los bloques se interpretan, los valores están disponibles en markdown -> se convierte
en PDF / html / ... que puedo publicar como artículo de revista. Diferente a un
portátil, ya que el portátil se basa en varias celdas y no estoy seguro de cómo
influir en si la salida se muestra o no).

No me importa cómo se incluyen los valores en el texto, pero lo encontraría
bueno si tanto R (con knitr / rstudio) como ipython usaran lo mismo.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment -46875435.

Me doy cuenta del caso de uso del código interpretado, por supuesto, solo me preocupa que perdamos la capacidad de Markdown para mostrar el código "solo" (sin interpretarlo / evaluarlo), like this , si la sintaxis R (es decir, comillas inversas ) fueron escogidos.

Creo que en el markdown de knitr / R puede indicar si desea mostrar el código (correctamente resaltado, etc.) o solo la salida (gráficos, tablas, ...).

Vengo de una experiencia en economía y no quiero ver ningún código en mis artículos, por lo que esto es un poco diferente al (en mi opinión) caso de uso optimizado de mostrar código.

@bilderbuchi oh lo siento, malinterpreté el contexto de tu comentario de "no creo que esto sea útil".

Y estoy de acuerdo: todo lo que se implemente no debe romper la rebaja existente.

Esto sería maravilloso y haría que IPython se comiera el almuerzo del tejedor.

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

Realmente me gusta este enfoque: toma una celda y la procesa previamente para obtener una rebaja válida, por lo que no se necesitan cambios en el procesador de rebajas.

muy bonito ... lo usaré pronto

El domingo, 17 de agosto de 2014 a las 2:18 p.m., Jan Schulz [email protected]
escribió:

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

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment -52431760.

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

: +1: elegante. Yo también lo usaré.

@JanSchulz , ¡gracias! Tengo muchas ganas de probar Python-Markdown.

¿Existe alguna posibilidad de introducir esto en ipython principal ( jupyter )?

¿Hay alguna posibilidad de que esto se lleve a ipython principal (jupyter)?

Probablemente no pronto. Necesitamos hacer mucho diseño en segundo plano para que esto funcione.
Especialmente necesitaríamos una forma oficial de extender la sintaxis de rebajas en lugar de simplemente inventar una nueva.

En realidad, esto (y también knitr / rmarkdown AFAIK) funciona al tener una conversión de dos etapas: primero el reemplazo de cualquier bloque de código con la salida del código y luego convertir el resto como rebaja estándar. Entonces, esto no es una extensión de Markdown, sino un preprocesador para una celda.

Creo que la pregunta difícil es cómo manejar código de Python invisible arbitrario que se ejecuta desde dentro de una celda de rebajas. No creo que la ejecución del código pueda restringirse en una implementación útil.

Siempre que sea una extensión separada que tenga que instalar y activar activamente, este es un asunto diferente. Además, el código Python solo se ejecuta si el cuaderno es de confianza.

Planeo agregar una información sobre herramientas que muestre el código fuente si pasa el cursor sobre la salida del código de Python en una celda de rebaja, para que pueda ver de dónde vino esto.

En realidad, esto (y también knitr / rmarkdown AFAIK) funciona al tener una conversión de dos etapas: primero el reemplazo de cualquier bloque de código con la salida del código y luego convertir el resto como rebaja estándar. Entonces, esto no es una extensión de Markdown, sino un preprocesador para una celda.

Que es una rebaja personalizada. Eso ya es lo que tenemos con mathjax. Obviamente tenemos que almacenar el
anular el preprocesamiento de la rebaja en caso de que vuelva a ejecutar el portátil, por lo que cualquier herramienta que desee utilizar nuestra rebaja tiene que ocuparse del preprocesamiento personalizado.
Antes o después del procesador, inventamos nuestra propia sintaxis, que puede o no entrar en conflicto con lo que la gente quiere hacer o hará más tarde.

Creo que la pregunta difícil es cómo manejar código de Python invisible arbitrario que se ejecuta desde dentro de una celda de rebajas. No creo que la ejecución del código pueda restringirse en una implementación útil.

Siempre que sea una extensión separada que tenga que instalar y activar activamente, este es un asunto diferente. Además, el código Python solo se ejecuta si el cuaderno es de confianza.

Planeo agregar una información sobre herramientas que muestre el código fuente si pasa el cursor sobre la salida del código de Python en una celda de rebaja, para que pueda ver de dónde vino esto.

Si hacemos eso, podríamos restringir a user_variable, es decir, devolver el valor de user_ns key. Eso debería evitar la mayoría de las ejecuciones.

Si hacemos eso, podríamos restringir a user_variable, es decir, devolver el valor de la clave user_ns. Eso debería evitar la mayoría de las ejecuciones.

También querrá permitir funciones de llamada. Un caso trivial sería formatear la salida o llamar a un _repr_ personalizado.

Me encantaría ver implementado algo como esto. Parece que la solución más sencilla es ejecutar células MD a través de un filtro Jinja. Esto se ha hecho antes. Ver dexi , por ejemplo.

Por otro lado, no creo que esto deba estar habilitado de forma predeterminada en todas las celdas. Jinja aumentaría considerablemente la complejidad del marcado y Jinja + Markdown probablemente debería usar un modo de resaltado diferente al MD simple. ¿Por qué no implementar esto como un tipo de celda independiente?

Creo que este problema podría desaparecer, si fuera posible que el código oculte / reemplace la celda del código de manera similar a lo que se hace actualmente para la rebaja:

-> Agregue un %%pymarkdown mágico, que genera un mensaje text/markdown e indica que la fuente debe ser invisible / reemplazada por la salida. La magia entonces simplemente haría un s & r dentro de la entrada.

[Editar: Ok, tiene diferentes problemas, como que no hay resaltado de sintaxis y no tiene sentido en la qtconsole ...]

Relevante: Mathematica 10 agregó soporte para "informes", consulte: http://www.wolfram.com/mathematica/new-in-10/automated-report-generation/

No he jugado (todavía) con él en detalle, pero parece que puede usar el cuaderno como plantillas, incrustando referencias a variables y resultados calculados en el texto del cuaderno.

Supongamos que tenemos múltiples referencias en múltiples celdas MD a la misma variable. ¿Qué celdas deberían volver a renderizarse cuando cambia su valor?

@Pipeliner No estoy seguro de a qué te refieres. En los cuadernos de iPython / Jupyter, cada celda debe ser renderizada explícitamente (ya sea mediante Ctrl-retorno desde dentro de la celda o desde Celda-> Ejecutar todo en la barra de menú). No hay una detección automática de datos obsoletos que yo sepa. ¿Estás pensando en knitr / rmarkdown? knitr / rmarkdown intenta mantener un caché de resultados de cada celda y los marca como sucios cuando cambian las celdas anteriores.

¿Hay alguna solución para este problema que está usando la gente? Me encantan los cuadernos ipython / jupyter, pero sería increíble si pudiéramos hacer {{variable python}} en la rebaja. Es muy útil si está preparando una computadora portátil con pequeños conjuntos de datos de muestra y luego desea intercambiar el conjunto completo y tener todo actualizado

Puede utilizar un widget PlaceProxy para representar un widget en cualquier selector html de la página. En su rebaja, inserte un <span id="myid">placeholder</span> , y luego en su código, use algo como x=HTML('widget value'), PlaceProxy(child=x, selector='#myid') . Luego, cada vez que establezca x.value='something' , la actualización se refleja en el widget que se muestra en la rebaja. Consulte https://github.com/ipython/ipywidgets/blob/1e407cef864363c66a23781b8d560a6ac18b3370/ipywidgets/widgets/widget_box.py#L70 para conocer la definición de PlaceProxy.

Muchas advertencias, por supuesto. si edita la rebaja, el widget desaparece. Si abre el cuaderno, es posible que el widget no se haya creado, por lo que no se mostrará, etc. Pero le permite controlar mediante programación una salida dentro de una celda de rebajas.

Otra opción es construir la cadena y mostrar la rebaja como una salida, no como una celda de rebaja. No se actualizará dinámicamente, pero cada vez que evalúe la celda, la rebaja se actualizará.

Podrías probar estas extensiones de portátil:
https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/python-markdown_v3

No quería construir la cadena y poner es la salida, ya que se vuelve tan complicado tener cadenas html grandes; sin embargo, es una buena idea, ni siquiera pensé en eso. Pero definitivamente hay un par de buenas soluciones que funcionan, ¡gracias!

Creo que esta característica es realmente importante para alguien que viene de Rmarkdown. R ha hecho un trabajo mucho mejor al crear buenos informes.

Vi un duplicado de este problema en el cuaderno. Esto ya es posible usando IPython.display.Markdown en una celda 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))

¡Bonito! También sería fácil escribir una utilidad (o incluso una magia de rebaja de %%)
que extraen automáticamente las variables del espacio de nombres del kernel, por lo que podría
hacer:

%%markdown

## Subsection

Here is {one} and {two}

El miércoles 26 de abril de 2017 a las 6:35 p. M., Grant Nestor [email protected]
escribió:

Vi un duplicado de este problema en el cuaderno. Esto ya es posible
usando IPython.display.Markdown en una celda de código:

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

desde IPython.display import Markdown

uno = 1
dos = 2
tres = uno + dos

Markdown ("# título")
Markdown ("" "# Matemáticas ## Suma Aquí hay un ejemplo de suma simple: {uno} + {dos} = {tres}" "". Formato (uno = uno, dos = dos, tres = tres))

-
Está recibiendo esto porque fue asignado.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-297586914 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AABr0CIHhxwNwQF6MiHHy2M612zRnf5Wks5rz_D4gaJpZM4AchzX
.

-
Brian E. Granger
Profesor asociado de física y ciencia de datos
Universidad Estatal de Cal Poly, San Luis Obispo
@ellisonbg en Twitter y GitHub
[email protected] y [email protected]

@ellisonbg Eso sería bueno y creo que esta es la forma correcta de hacerlo (renderizar la rebaja de Python frente a extender la maquinaria marcada y otra de rebaja de manera que tal vez no debería extenderse). @Carreau ¿Te interesa algo como esto?

Además, combinando esto con la nueva función de etiquetas de celda en el cuaderno (consulte la publicación de la versión 5.0 del nbconvert-hide ). @takluyver ¿ nbconvert-hide con nbconvert?

No creo que lo haga todavía, pero creo que deberíamos agregar algunas etiquetas nbconvert.

+1 a todo esto! Además, actualmente estamos trabajando para ocultar entradas / salidas en
JupyterLab y podrá persistir ese estado en nbconvert
metadatos.

El jueves 27 de abril de 2017 a las 7:33 a. M., Grant Nestor [email protected]
escribió:

@ellisonbg https://github.com/ellisonbg Eso sería bueno y creo que
esta es la forma correcta de hacerlo (reducción de rendimiento de Python vs.
extender la maquinaria marcada y otra de rebajas de manera que tal vez
no debe extenderse). @Carreau https://github.com/Carreau Cualquiera
interés en algo como esto?

Además, combinando esto con la nueva función de etiquetas de celda en el cuaderno
(ver la publicación de la versión 5.0 del notebook
http://blog.jupyter.org/2017/04/04/jupyter-notebook-5-0/ ), debería
ser capaz de ocultar celdas de entrada al convertir un cuaderno usando nbconvert
(por ejemplo, usando la etiqueta nbconvert-hide). @takluyver https://github.com/takluyver
¿La etiqueta nbconvert-hide funciona actualmente con nbconvert?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-297731409 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AABr0BNgLTtlzwbrIjqBquzsE9lhLXchks5r0KdAgaJpZM4AchzX
.

-
Brian E. Granger
Profesor asociado de física y ciencia de datos
Universidad Estatal de Cal Poly, San Luis Obispo
@ellisonbg en Twitter y GitHub
[email protected] y [email protected]

@Carreau ¿Te interesa algo como esto?

Esta forma de hacer las cosas ya se discutió en 2013 algo y AFAICT fue mal visto como:

• necesita reimplementar %% markdown en todos los idiomas
• Requiere cálculo en el lado del kernel para mostrar texto.
• cambia el significado semántico de hacer una rebaja.
• arruinar nbconvert --to markdown y nbconvert --to script
• anzuelos de importación de cuadernos estropeados.

Eso es romper la semántica del cuaderno (en mi humilde opinión), porque entonces el texto de las celdas de "rebajas" depende del estado del kernel. Entonces, si bien es lindo, rechazaré esta idea.

También la magia %%markdown , %%latex , %%javascript ... etc se escribieron en el momento en que estábamos teniendo esta discusión.

Notaré que han existido magias similares durante bastante tiempo y características mucho más avanzadas que simplemente usar %%markdown , así que no se apresure porque ha salido, ya que nunca antes se había encontrado con esta idea.

Mi pensamiento ha evolucionado con el tiempo y me gusta la idea de @gnestor .

Por definición, si un usuario quiere variables del kernel en la celda de rebajas,
esa celda de rebajas dependerá del kernel. Decir "eso rompe el
semántica del notebok "es como decir que no deberíamos permitir celdas de código
porque se ejecutan en el kernel y devuelven la salida. Uno de los propósitos principales
del documento del cuaderno sirve como registro de lo que hace el kernel.
La implementación en cualquier kernel que admita salida enriquecida es trivial y
esto rompe cualquier cosa aguas abajo (nbconvert, import hooks) luego esas cosas
tienen errores (la salida de Markdown ya es una cosa).

Pero estoy bien haciendo esto fuera del kernel de ipython ...

El jueves 27 de abril de 2017 a las 10:29 a. M., Matthias Bussonnier <
[email protected]> escribió:

@Carreau https://github.com/Carreau ¿ Te interesa algo como esto?

Esta forma de hacer las cosas ya se discutió en 2013 algo y
AFAICT fue mal visto como:

• necesita reimplementar %% markdown en todos los idiomas
• Requiere cálculo en el lado del kernel para mostrar texto.
• cambia el significado semántico de hacer una rebaja.
• arruinar nbconvert --to markdown y nbconvert --to script
• anzuelos de importación de cuadernos estropeados.

Eso es romper la semántica del cuaderno (en mi humilde opinión), porque luego el texto de
las celdas de "rebajas" dependen del estado del kernel. Así que, si bien es lindo, me voy
para rechazar esta idea.

También el %% markdown, %% latex, %% javascript ... etc magic se escribieron en
el momento en que estábamos teniendo esta discusión.

Notaré que han existido magias similares durante bastante tiempo.
https://gist.github.com/bj0/5343292 y funciones mucho más avanzadas que
simplemente usando %% markdown, así que no se apresure porque ha salido como
nunca antes te has encontrado con esta idea.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-297784026 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AABr0HU-Gb3ENSidykbte53geYqPpy-sks5r0NCAgaJpZM4AchzX
.

-
Brian E. Granger
Profesor asociado de física y ciencia de datos
Universidad Estatal de Cal Poly, San Luis Obispo
@ellisonbg en Twitter y GitHub
[email protected] y [email protected]

Implementación de referencia (extensión de cuaderno clásico): https://github.com/ipython-contrib/jupyter_contrib_nbextensions/blob/master/src/jupyter_contrib_nbextensions/nbextensions/python-markdown/main.js

Creo que esta es la forma correcta de hacerlo (renderizando markdown desde Python

Solo aclaro, ya que inicialmente leí mal su declaración: esto es usar el kernel para mostrar la rebaja (como un tipo mime de rebaja), no para representar la rebaja en html. La reducción real de la representación a html todavía se realiza en el lado del cliente, en nbconvert, etc.

Me gusta este enfoque. Si desea una rebaja sencilla que implique el estado del kernel, utilice el kernel para mostrar esa rebaja. Si desea que esa rebaja se actualice en vivo, utilice un widget (podría usar un OutputWidget, o podríamos hacer un MarkdownWidget similar al HTMLWidget). Esto, acompañado de formas sencillas de ocultar / mostrar entradas y salidas, tiene mucho sentido para mí.

Acabo de encontrar este ticket y me gustaría mencionar que SoS también adoptó el enfoque mencionado anteriormente, es decir, renderizar la reducción del kernel. Básicamente, sos implementa una magia %render que muestra la salida estándar de una celda en MD (por defecto), HTML, etc., y debido a que sos admite diferentes idiomas, también genera la salida de cualquier subkernel en el que se inicia.

Aquí hay una solución simple: https://github.com/jupyter/nbconvert/issues/320

Sería bueno que pase lo que pase también pudiera ser compatible con RMarkdown. Que usa

 El valor de x es `rx`.

Donde x es una variable en R.

https://github.com/vatlab/markdown-kernel no es necesariamente lo que necesita, pero admite celdas Rmarkdown en un entorno Jupyter.

TL; DR: ¿este hilo aún está actualizado? JupyterLab no tiene una solución directa, pero ¿Notebook la tiene? (2020)

Entonces ... leyendo este hilo y probando los diversos trucos sugeridos ... parece que a partir de 2020 esta función aún es imposible / falta en JupyterLab (¿que el sitio principal ha estado presionando a las personas a usar durante varios años?), a menos que use SoS (todas las otras soluciones parecen ser solo para notebooks, es decir, heredadas / inútiles para instalaciones modernas ... o requieren desechar la mayor parte de la conveniencia de usar la funcionalidad principal de "código + rebaja" de Jupyter).

¿Hay algo que me haya perdido? Parece que el JupyterLab principal (nota: no los Notebooks, que funcionan bien, y me siento un poco traicionado de que el proyecto principal empuje a Lab tan duro cuando los Notebooks claramente funcionan mucho mejor, incluso ahora en 2020) esencialmente no admite rebajas en docs para cualquier cosa más allá de trivial, no análisis, ejemplos, retóricamente hablando: ¿cuál es el punto de incluir un sistema de formato en un producto de análisis de datos si no puede generar sus datos con el formato?

Esto parece tan incorrecto que creo que debo haberme perdido algo básico. "SoS + markdown-kernel" se siente como un mazo para romper una nuez, pero como funciona ...