Ipython: Autoriser les références aux variables Python dans les cellules Markdown

alors, est-ce mort ? Ce serait génial comme l'a souligné le fil précédent? Désolé de cogner, j'aurais aimé avoir le savoir-faire à mettre en œuvre (je ne le fais pas) mais j'utiliserais certainement...

Pas mort, juste besoin de faire quelques choses d'abord.

Je viens de poser des questions à ce sujet sur SO , seulement pour découvrir qu'il s'agissait d'un double doublon d' ici et d' ici .

Mon 2c serait ça

• La syntaxe Jinja serait géniale
• D'un coup d'œil rapide, il semble que le markdown n'ait pas vraiment de "pur" , mais si toutes les conventions de formatage d'une implémentation bien établie ( :octocat: github serait une bonne chose) étaient suivies, l'ajout d'une méthode d'injection n'est pas en fait un problème de démarque.
• les erreurs pourraient-elles être une chose configurable par l'utilisateur ? Une option de [invisible (rien ne se passe), le mot error , ou une sale trace de pile ]
• Tant qu'il s'agit d'une réponse textuelle, elle pourrait être injectée avant d'être transmise au moteur de rendu Markdown, de sorte qu'elle pourrait injecter du html ou encore plus de démarques !

Ne pas préconiser une syntaxe particulière (je pense que {{}} est bien), mais voici une conception comparable pour R : http://www.rstudio.com/ide/docs/authoring/using_markdown (Ils utilisent ``` comme délimiteur ).

Lunamark utilise

:+1:

:+1:, ce serait une fonctionnalité très utile !

Ce serait vraiment bien d'avoir la même syntaxe que http://blog.rstudio.org/2014/06/18/r-markdown-v2/

Je ne sais pas, en utilisant les délimiteurs de style R, c'est-à-dire des backticks simples et triples, respectivement, il semble que nous ne puissions pas choisir entre simplement afficher le code (comme some code snippet/example ), et _évaluer_ le code et afficher le résultat ( par exemple my_var ) - Je ne pense pas que ce soit très pratique (si je comprends bien).

Le cas d'utilisation consiste à écrire de la prose pour cahier avec des valeurs calculées intégrées, telles que "_Le chômage moyen pour le comté de Morgan en 2014 était de 8,4%, contre 10,3% en 2009._" Dans cet exemple, vous pouvez imaginer les pourcentages et les années calculés à partir de Les données.

Le cas d'utilisation le plus large est celui des « documents intelligents », où vous avez automatiquement (re)généré du texte et des graphiques (cachant peut-être le code pour la lisibilité) à partir des données.

Je pense que c'est une fonctionnalité utile.

J'aime beaucoup le modèle "knitr" de rstudio (un document markdown, les blocs de code sont interprétés, les valeurs sont disponibles dans markdown -> sont converties en PDF/html/... que je peux publier en tant qu'article de journal. Différent d'un cahier car le bloc-notes est basé sur plusieurs cellules et je ne sais pas comment influencer si la sortie est affichée ou non).

Cela ne me dérange pas de savoir comment les valeurs sont incluses dans le texte, mais je trouverais bien si R (avec knitr/rstudio) et ipython utilisaient la même chose.

Ou quelque chose de similaire à ruby ​​ou bash, où #{varname or statement} peut être
mélangé dans la chaîne.

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

J'aime beaucoup le modèle "knitr" dans rstudio (un document markdown, code
les blocs sont interprétés, les valeurs sont disponibles dans Markdown -> est converti
en PDF/html/... que je peux publier sous forme d'article de journal. Différent d'un
notebook car le notebook est basé sur plusieurs cellules et je ne sais pas comment
influencer si la sortie est affichée ou non).

Cela ne me dérange pas de savoir comment les valeurs sont incluses dans le texte, mais je le trouverais
bien si R (avec knitr/rstudio) et ipython utilisaient le même.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment -46875435.

Je me rends compte du cas d'utilisation du code interprété bien sûr, je crains juste que nous perdions la capacité de Markdown à "juste" afficher le code (sans l'interpréter/l'évaluer), like this , si la syntaxe R (c'est-à-dire backticks ) ont été choisi.

Je pense que dans knitr/R markdown, vous pouvez indiquer si vous souhaitez afficher le code (correctement mis en évidence, etc.) ou uniquement la sortie (traces, tableaux, ...).

Je viens du milieu de l'économie et je ne veux voir aucun code dans mes articles, c'est donc un peu différent du cas d'utilisation optimisé (à mon avis) de montrer du code.

@bilderbuchi oh désolé, j'ai mal interprété le contexte de votre commentaire "ne pense pas que ce soit utile".

Et je suis d'accord : tout ce qui est mis en œuvre ne doit pas casser la démarque existante.

Ce serait merveilleux et ferait en sorte qu'IPython mange le déjeuner de la tricoteuse.

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

J'aime vraiment cette approche : il faut une cellule et la prétraiter pour valider la démarque, de sorte qu'aucune modification du processeur de démarque n'est nécessaire.

très agréable... utilisera bientôt

Le dimanche 17 août 2014 à 14h18, Jan Schulz [email protected]
a écrit:

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

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-52431760 .

Tom Brander
http://tombrander.com -Immobilier
http://oswco.com - Logiciel ouvert
3763, boulevard West Jackson
Birmingham, AL 35213
Téléphone 205-267-1089
@dartdog

:+1: élégant. Je vais utiliser aussi.

@JanSchulz , merci ! J'ai vraiment hâte d'essayer python-markdown.

Y a-t-il une chance de l'intégrer à l'ipython principal ( jupyter ) ?

Y a-t-il une chance de l'intégrer dans ipython principal (jupyter)?

Probablement pas de sitôt. Nous devons faire beaucoup de design en arrière-plan pour que cela fonctionne.
En particulier, nous aurions besoin d'un moyen officiel d'étendre la syntaxe de démarque au lieu de simplement en inventer une nouvelle.

En fait, cela (ainsi que knitr/rmarkdown AFAIK) fonctionne en ayant une conversion en deux étapes : d'abord le remplacement de tous les blocs de code avec la sortie du code, puis convertir le reste en démarque standard. Ce n'est donc pas une extension de démarque mais un préprocesseur pour une cellule.

Je pense que la question difficile est de savoir comment gérer le code Python invisible arbitraire qui est exécuté à partir d'une cellule de démarque. Je ne pense pas que l'exécution de code puisse être restreinte dans une implémentation utile.

Tant qu'il s'agit d'une extension distincte que vous devez activement installer et activer, c'est une autre affaire. De plus, le code Python n'est exécuté que si le notebook est fiable.

Je prévois d'ajouter une info-bulle montrant le code source si vous survolez la sortie du code python dans une cellule de démarque, afin que vous puissiez voir d'où cela vient.

En fait, cela (ainsi que knitr/rmarkdown AFAIK) fonctionne en ayant une conversion en deux étapes : d'abord le remplacement de tous les blocs de code avec la sortie du code, puis convertir le reste en démarque standard. Ce n'est donc pas une extension de démarque mais un préprocesseur pour une cellule.

Ce qui est une démarque personnalisée. C'est déjà ce que nous avons avec mathjax. Nous devons évidemment stocker les
un-preprocess markdown au cas où vous réexécutez le bloc-notes, de sorte que tout outil qui souhaite utiliser notre démarque doit gérer le prétraitement personnalisé.
Pré ou post processeur, nous inventons notre propre syntaxe, qui peut ou non entrer en conflit avec ce que les gens veulent faire, ou feront plus tard.

Je pense que la question difficile est de savoir comment gérer le code Python invisible arbitraire qui est exécuté à partir d'une cellule de démarque. Je ne pense pas que l'exécution de code puisse être restreinte dans une implémentation utile.

Tant qu'il s'agit d'une extension distincte que vous devez activement installer et activer, c'est une autre affaire. De plus, le code Python n'est exécuté que si le notebook est fiable.

Je prévois d'ajouter une info-bulle montrant le code source si vous survolez la sortie du code python dans une cellule de démarque, afin que vous puissiez voir d'où cela vient.

Si nous faisons cela, nous pourrions restreindre à user_variable, c'est-à-dire retourner la valeur de la clé user_ns . Cela devrait empêcher la plupart des exécutions.

Si nous faisons cela, nous pourrions nous restreindre à user_variable, c'est-à-dire retourner la valeur de la clé user_ns. Cela devrait empêcher la plupart des exécutions.

Vous voudrez également autoriser les fonctions d'appel. Un cas trivial serait de formater la sortie ou d'appeler un _repr_ personnalisé.

J'aimerais voir quelque chose comme ça mis en œuvre. Il semble que la solution la plus simple consiste à faire passer les cellules MD à travers un filtre Jinja. Cela a déjà été fait. Voir dexi , par exemple.

D'un autre côté, je ne pense pas que cela devrait être activé par défaut dans toutes les cellules. Jinja augmenterait considérablement la complexité du balisage et Jinja+Markdown devrait probablement utiliser un mode de surbrillance différent du simple MD. Pourquoi ne pas l'implémenter en tant que type de cellule distinct ?

Je pense que ce problème pourrait disparaître, s'il était possible à partir du code de masquer/remplacer la cellule de code similaire à ce qui est fait pour le démarquage actuellement :

-> Ajoutez un %%pymarkdown magique, qui génère un message text/markdown et indique que la source doit être invisible/remplacée par la sortie. La magie ferait alors simplement un s&r dans l'entrée.

[Edit : Ok, il a des problèmes différents, comme l'absence de coloration syntaxique et n'a aucun sens dans la qtconsole...]

Pertinent : Mathematica 10 a ajouté la prise en charge des « rapports », voir : http://www.wolfram.com/mathematica/new-in-10/automated-report-generation/

Je n'ai pas (encore) joué avec lui en détail, mais il semble que vous puissiez utiliser le bloc-notes comme modèles, en incorporant des références à des variables et à une sortie calculée dans le texte du bloc-notes.

Supposons que nous ayons plusieurs références dans plusieurs cellules MD à la même variable. Quelles cellules doivent être à nouveau rendues lorsqu'elles changent de valeur ?

@Pipeliner Je ne sais pas où vous voulez en venir. Dans les cahiers iPython/Jupyter, chaque cellule doit être explicitement rendue (soit via Ctrl-retour depuis la cellule ou depuis Cell->Run All dans la barre de menus). À ma connaissance, il n'y a pas de détection automatique des données périmées. Pensez-vous à knitr/rmarkdown ? knitr/rmarkdown essaie de conserver un cache des résultats de chaque cellule et les marque comme sales lorsque les cellules précédentes changent.

existe-t-il des solutions de contournement pour ce problème que les gens utilisent ?. J'adore les cahiers ipython/jupyter mais ce serait incroyable si nous pouvions simplement faire {{ python variable }} dans la démarque. C'est tellement pratique si vous préparez un bloc-notes avec un petit échantillon de jeux de données et que vous voulez plus tard échanger dans l'ensemble complet et tout mettre à jour

Vous pouvez utiliser un widget PlaceProxy pour afficher un widget sur n'importe quel sélecteur HTML de la page. Dans votre démarque, intégrez un <span id="myid">placeholder</span> , puis plus tard dans votre code, utilisez quelque chose comme x=HTML('widget value'), PlaceProxy(child=x, selector='#myid') . Ensuite, chaque fois que vous définissez x.value='something' , la mise à jour est reflétée dans le widget qui est affiché dans la démarque. Voir https://github.com/ipython/ipywidgets/blob/1e407cef864363c66a23781b8d560a6ac18b3370/ipywidgets/widgets/widget_box.py#L70 pour la définition de PlaceProxy.

Beaucoup de mises en garde, bien sûr. si vous modifiez la démarque, le widget disparaît. Si vous ouvrez le bloc-notes, le widget n'a peut-être pas été créé, il ne s'affichera donc pas, etc. Mais il vous permet de contrôler par programme une sortie à l'intérieur d'une cellule de démarque.

Une autre option consiste à construire la chaîne et à afficher la démarque en tant que sortie, et non en tant que cellule de démarque. Il ne sera pas mis à jour de manière dynamique, mais chaque fois que vous évaluerez la cellule, la démarque sera mise à jour.

Vous pouvez essayer ces extensions de notebook :
https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/python-markdown_v3

Je ne voulais pas construire la chaîne et la mettre comme sortie car cela devient tellement compliqué d'avoir de grosses chaînes html - bonne idée cependant, je n'y ai même pas pensé. Mais il y a certainement quelques bonnes solutions qui font l'affaire - merci !

Je pense que cette fonctionnalité est vraiment importante pour quelqu'un qui vient de Rmarkdown. R a fait un bien meilleur travail en créant de beaux rapports.

J'ai vu un doublon de ce problème dans le cahier. C'est déjà possible en utilisant IPython.display.Markdown dans une cellule de code :

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

Joli! Il serait aussi facile d'écrire un utilitaire (ou même une magie %%markdown)
qui extrait automatiquement les variables de l'espace de noms du noyau, vous pouvez donc
faire:

%%markdown

## Subsection

Here is {one} and {two}

Le mer. 26 avril 2017 à 18h35, Grant Nestor [email protected]
a écrit:

J'ai vu un doublon de ce problème dans le cahier. c'est déjà possible
en utilisant IPython.display.Markdown dans une cellule de code :

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

depuis IPython.display importer Markdown

un = 1
deux = 2
trois = un + deux

Markdown ("# Titre")
Markdown("""# Math## AdditionVoici un exemple d'addition simple : {un} + {deux} = {trois}""".format(un=un, deux=deux, trois=trois))

-
Vous recevez ceci parce que vous avez été affecté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-297586914 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AABr0CIHhxwNwQF6MiHHy2M612zRnf5Wks5rz_D4gaJpZM4AchzX
.

--
Brian E. Granger
Professeur agrégé de physique et de science des données
Université d'État Cal Poly, San Luis Obispo
@ellisonbg sur Twitter et GitHub
[email protected] et [email protected]

@ellisonbg Ce serait bien et je pense que c'est la bonne façon de le faire (rendre la démarque de Python par rapport à l'extension des machines de démarques marquées et autres de manière à ne pas l'étendre). @Carreau Un intérêt pour quelque chose comme ça ?

De plus, en combinant cela avec la nouvelle fonctionnalité de balises de cellule dans notebook (voir la publication de la version nbconvert-hide ). @takluyver La balise nbconvert-hide fonctionne-t-elle actuellement avec nbconvert ?

Je ne pense pas que ce soit le cas pour le moment, mais je pense que nous devrions ajouter des balises nbconvert.

+1 à tout ça ! De plus, nous travaillons actuellement sur le masquage des entrées/sorties dans
JupyterLab et pourra faire persister cet état au nbconvert
métadonnées.

Le jeu. 27 avril 2017 à 7h33, Grant Nestor [email protected]
a écrit:

@ellisonbg https://github.com/ellisonbg Ce serait bien et je pense
c'est la bonne façon de le faire (rendre la démarque de Python vs.
étendre les machines marquées et autres démarcations de manière à ce qu'elles
ne devrait pas être prolongé). @Carreau https://github.com/Carreau Tout
intérêt pour quelque chose comme ça?

De plus, en combinant cela avec la nouvelle fonctionnalité de balises de cellule dans le bloc-notes
(voir l'article sur la version du notebook 5.0
http://blog.jupyter.org/2017/04/04/jupyter-notebook-5-0/ ), vous devriez
pouvoir masquer les cellules d'entrée lors de la conversion d'un bloc-notes à l'aide de nbconvert
(par exemple en utilisant la balise nbconvert-hide). @takluyver https://github.com/takluyver
La balise nbconvert-hide fonctionne-t-elle actuellement avec nbconvert ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-297731409 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AABr0BNgLTtlzwbrIjqBquzsE9lhLXchks5r0KdAgaJpZM4AchzX
.

--
Brian E. Granger
Professeur agrégé de physique et de science des données
Université d'État Cal Poly, San Luis Obispo
@ellisonbg sur Twitter et GitHub
[email protected] et [email protected]

@Carreau Un intérêt pour quelque chose comme ça ?

Cette façon de faire a déjà été discutée en 2013 quelque chose et AFAICT a été mal vu comme :

• vous devez réimplémenter %%markdown dans toutes les langues
• il nécessite un calcul côté noyau pour afficher le texte
• cela change le sens sémantique du rendu d'une démarque.
• bousiller nbconvert --to markdown et nbconvert --to script
• les cahiers foutus importent des crochets.

C'est casser la sémantique du cahier (IMHO), car alors le texte des cellules "markdown" dépend de l'état du noyau. Donc, même si c'est mignon, je vais voter contre cette idée.

Aussi les %%markdown , %%latex , %%javascript ... etc magie ont été écrites à l'époque où nous avions cette discussion.

Je noterai que des magies similaires existent depuis un certain temps et des fonctionnalités bien plus avancées que la simple utilisation de %%markdown , alors ne vous précipitez pas car vous êtes sorti car vous n'avez jamais rencontré cette idée auparavant.

Ma réflexion a évolué avec le temps et j'aime l'idée de @gnestor .

Par définition, si un utilisateur veut des variables du noyau dans la cellule de démarque,
cette cellule de démarque dépendra du noyau. Dire "ça brise le
sémantique du bloc-notes", c'est comme dire que nous ne devrions pas autoriser les cellules de code
car ils s'exécutent sur le noyau et renvoient une sortie. L'un des principaux objectifs
du document notebook est de servir d'enregistrement de ce que fait le noyau.
L'implémentation sur n'importe quel noyau prenant en charge une sortie riche est triviale et elle
cela casse quoi que ce soit en aval (nbconvert, import hooks) puis ces choses
avoir des bugs (la sortie de démarque est déjà une chose).

Mais je vais bien le faire en dehors du noyau ipython ...

Le jeu. 27 avr. 2017 à 10:29, Matthias Bussonnier <
[email protected]> a écrit :

@Carreau https://github.com/Carreau Un intérêt pour quelque chose comme ça ?

Cette façon de faire a déjà été discutée en 2013 quelque chose et
AFAICT était mal vu comme :

• vous devez réimplémenter %%markdown dans toutes les langues
• il nécessite un calcul côté noyau pour afficher le texte
• cela change le sens sémantique du rendu d'une démarque.
• bousiller nbconvert --to markdown et nbconvert --to script
• les cahiers foutus importent des crochets.

C'est casser la sémantique du cahier (à mon humble avis), car alors le texte de
les cellules "markdown" dépendent de l'état du noyau. Alors tant que c'est mignon je vais
de voter contre cette idée.

De plus, les %%markdown, %%latex, %%javascript ... etc magiques ont été écrits à
l'époque où nous avions cette discussion.

Je note que des magies similaires existent depuis un certain temps
https://gist.github.com/bj0/5343292 et des fonctionnalités bien plus avancées que
en utilisant simplement %%markdown, alors s'il vous plaît ne vous précipitez pas parce que vous êtes sorti en tant que
vous n'avez jamais rencontré cette idée auparavant.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ipython/ipython/issues/2958#issuecomment-297784026 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AABr0HU-Gb3ENSidykbte53geYqPpy-sks5r0NCAgaJpZM4AchzX
.

--
Brian E. Granger
Professeur agrégé de physique et de science des données
Université d'État Cal Poly, San Luis Obispo
@ellisonbg sur Twitter et GitHub
[email protected] et [email protected]

Implémentation de référence (extension de cahier classique) : https://github.com/ipython-contrib/jupyter_contrib_nbextensions/blob/master/src/jupyter_contrib_nbextensions/nbextensions/python-markdown/main.js

Je pense que c'est la bonne façon de le faire (rendre la démarque de Python

Juste une clarification puisque j'ai mal lu votre déclaration au départ - cela utilise le noyau pour afficher le markdown (en tant que type mime markdown), pas pour rendre le markdown en html. La réduction de rendu réelle en html est toujours en cours côté client, dans nbconvert, etc.

J'aime cette approche. Si vous voulez une démarque facile qui implique l'état du noyau, utilisez le noyau pour afficher cette démarque. Si vous voulez que ce markdown soit mis à jour en direct, utilisez un widget (vous pouvez utiliser un OutputWidget, ou nous pourrions créer un MarkdownWidget similaire au HTMLWidget). Ceci, accompagné de moyens simples de masquer/afficher les entrées et les sorties, a beaucoup de sens pour moi.

Je viens de tomber sur ce ticket et j'aimerais mentionner que SoS a également adopté l'approche susmentionnée, à savoir le rendu de la démarque à partir du noyau. Fondamentalement, sos implémente une magie %render qui rend la sortie standard d'une cellule dans MD (par défaut), HTML etc, et parce que sos prend en charge différentes langues, il rend également la sortie de n'importe quel sous-noyau qu'il démarre.

Voici une solution simple : https://github.com/jupyter/nbconvert/issues/320

Ce serait bien si quoi qu'il arrive puisse aussi être compatible avec RMarkdown. qui utilise

 La valeur de x est "rx".

Où x est une variable dans R.

https://github.com/vatlab/markdown-kernel n'est pas nécessairement ce dont vous avez besoin, mais il prend en charge les cellules Rmarkdown dans un environnement Jupyter.

TL;DR : ce fil est-il toujours à jour ? JupyterLab n'a pas de solution directe, mais Notebook en a ? (2020)

Donc... en lisant ce fil, et en essayant les différents hacks suggérés... il semble qu'en 2020 cette fonctionnalité soit toujours impossible/manquante dans JupyterLab (que le site principal pousse les gens à utiliser depuis plusieurs années maintenant ?), à moins que vous n'utilisiez SoS (toutes les autres solutions de contournement semblent être réservées aux ordinateurs portables, c'est-à-dire héritées / inutiles pour les installations modernes ...

Y a-t-il quelque chose que j'ai raté ? Il semble que le JupyterLab principal (remarque: pas les Notebooks, qui fonctionnent bien, et je me sens un peu trahi que le projet principal pousse Lab si fort alors que les Notebooks fonctionnent clairement beaucoup mieux, même maintenant en 2020) ne prend essentiellement pas en charge la démarque dans docs pour tout ce qui va au-delà du trivial, de la non-analyse, des exemples - du point de vue rhétorique : quel est l'intérêt d'inclure un système de formatage dans un produit d'analyse de données si vous ne pouvez pas sortir vos données avec le formatage ?

Cela semble si faux que je pense que j'ai dû manquer quelque chose de fondamental. "SoS + markdown-kernel" ressemble à un marteau pour casser une noix, mais comme cela fonctionne ...