Allow references to Python variables in Markdown cells #2958
Comments
ghost
assigned 
|
so,, is this dead? It would be great as the prior thread pointed out? Sorry to bump wish I had the skilz to implement ( I don't) but I sure would use... |
|
Not dead, just need to get a few things done first. |
|
I just asked about this on SO, only to find that it was a double duplicate from here and here. My 2c would be that
|
github would be a nice one) were followed then adding an injection method isn't actually a markdown issue.
|
Not to advocate any particular syntax (I think {{}} is fine), but here's comparable design for R: http://www.rstudio.com/ide/docs/authoring/using_markdown (They use ``` as the delimiter). Lunamark uses <!--@ for "metadata", see: http://jgm.github.io/lunamark/lunamark.1.html |
|
👍 |
|
👍, this would be a very useful feature! |
|
It would be really nice to have the same syntax as http://blog.rstudio.org/2014/06/18/r-markdown-v2/ |
|
I don't know, using the R-style delimiters, i.e. single and triple backticks, respectively, it seems we couldn't choose between just displaying code (like |
|
The use case is writing notebook prose with embedded computed values, such as "The average unemployment for Morgan County in 2014 was 8.4%, down from 10.3% in 2009." In this example, you could imagine the percentages and years being calculated from data. The broader use case is "smart documents", where you have text and graphics automatically (re) generated (perhaps hiding the code for readability) from data. I think it's a useful feature. |
|
I really like the "knitr" model in rstudio (one markdown document, code blocks get interpreted, values are available in markdown -> gets converted into PDF/html/... which I can publish as an journal article. Different to a notebook as the notebook is based on multiple cells and I'm not sure how to influence whether output is shown or not). I don't mind how the values are included in the text, but I would find it nice if both R (with knitr/rstudio) and ipython would use the same. |
|
Or something similar to ruby or bash, where #{varname or statement} can be
|
|
I realize the use case of interpreted code of course, I'm just concerned that we would lose markdown's ability to "just" display code (without interpreting/evaluating it), |
|
I think in knitr/R markdown you can indicate whether you want to display code (properly highligted, etc) or only the output (plots, tables,...). I'm coming from an economics background and I don't want to see any code in my papers, so this is a bit different to the (in my opinion) optimized usecase of showing off code. |
|
@bilderbuchi oh sorry, I misinterpreted the context of your "don't think this is useful" comment. And I agree: whatever's implemented should not break existing markdown. |
|
This would be wonderful and make IPython eat knitr's lunch. |
|
https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/python-markdown I really like this approach: it takes a cell and preprocess it to valid markdown, so no changes to the markdown processor are needed. |
|
very nice...will use soon On Sun, Aug 17, 2014 at 2:18 PM, Jan Schulz notifications@github.com
Tom Brander |
|
👍 elegant. I will use as well. |
|
@JanSchulz, thanks! I really look forward to trying out python-markdown. |
|
Is there any chance of getting this into main ipython ( |
Probably not soon. We need to do a lot of design in the background to have this to work. |
|
Actually this (and also knitr/rmarkdown AFAIK) works by having a two stage conversion: first the replacement of any codeblocks with the output of the code and then convert the rest as standard markdown. So this is not an extension of markdown but a preprocessor for a cell. |
|
I think the hard question is how to handle arbitrary invisible Python code that is executed from within a markdown cell. I don't think execution of code can be restricted in a useful implementation. As long as it is a separate extension you actively have to install and activate, this is a different matter. Also, Python code only gets executed if the notebook is trusted. I plan to add a tooltip showing the source code if you hover over the output of the python code in a markdown cell, so you can see where this came from. |
Which is custom markdown. That's already what we have with mathjax. We obviously have to store the
If we do that, we could restrain to user_variable, ie return the value of |
You will also want to allow calling functions. A trivial case would be formatting the output or calling a custom repr. |
|
I would love to see something like this implemented. It looks like the most straightforward solution is to run MD cells through a Jinja filter. This has been done before. See dexi, for example. On the other hand, I don't think this should be enabled by default in all cells. Jinja would increase the complexity of the mark-up considerably and Jinja+Markdown should probably use different highlighting mode than plain MD. Why not implement this as a separate cell type? |
|
I think this problem could go away, if it would be possible from code to hide/replace the code cell similar what is done for markdown currently: -> Add a [Edit: Ok, it has different problems, like no syntax highlighting and making no sense in the qtconsole...] |
|
You could try this notebook extensions: |
|
I didn't want to to the construct the string and put is as output as it just gets so messy having big html strings - neat idea though, I didn't even think of that. But there are definitely a couple of good solutions which do the trick - thanks! |
|
I think this feature is really important to have for someone who comes from Rmarkdown. R has done a much better job in creating nice reports. |
|
I saw a duplicate of this issue in notebook. This is already possible using
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)) |
|
Nice! It would also be easy to write a utility (or even a %%markdown magic)
that automatically pull variables from the kernels namespace, so you could
do:
```
%%markdown
## Subsection
Here is {one} and {two}
```
…On Wed, Apr 26, 2017 at 6:35 PM, Grant Nestor ***@***.***> wrote:
I saw a duplicate of this issue in notebook. This is already possible
using IPython.display.Markdown in a code cell:
[image: image]
<https://cloud.githubusercontent.com/assets/512354/25464012/f434c52c-2aae-11e7-9171-541fb0f6601e.png>
from IPython.display import Markdown
one = 1
two = 2
three = one + two
Markdown("# Title")
Markdown("""# Math## AdditionHere is a simple addition example: {one} + {two} = {three}""".format(one=one, two=two, three=three))
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#2958 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABr0CIHhxwNwQF6MiHHy2M612zRnf5Wks5rz_D4gaJpZM4AchzX>
.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com
|
|
@ellisonbg That would be nice and I think this is the right way to do it (rendering markdown from Python vs. extending marked and other markdown machinery in ways that it maybe shouldn't be extended). @Carreau Any interest in something like this? Additionally, combining this with the new cell tags feature in notebook (see the notebook 5.0 release post), you should be able to hide input cells when converting a notebook using nbconvert (e.g. using |
|
I don't think it does yet, but I think we should add some nbconvert tags. |
|
+1 to all this! Also, we are currently working on hiding inputs/outputs in
JupyterLab and will be able to persist that state to the nbconvert
metadata.
…On Thu, Apr 27, 2017 at 7:33 AM, Grant Nestor ***@***.***> wrote:
@ellisonbg <https://github.com/ellisonbg> That would be nice and I think
this is the right way to do it (rendering markdown from Python vs.
extending marked and other markdown machinery in ways that it maybe
shouldn't be extended). @Carreau <https://github.com/Carreau> Any
interest in something like this?
Additionally, combining this with the new cell tags feature in notebook
(see the notebook 5.0 release post
<http://blog.jupyter.org/2017/04/04/jupyter-notebook-5-0/>), you should
be able to hide input cells when converting a notebook using nbconvert
(e.g. using nbconvert-hide tag). @takluyver <https://github.com/takluyver>
Does the nbconvert-hide tag currently work with nbconvert?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2958 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABr0BNgLTtlzwbrIjqBquzsE9lhLXchks5r0KdAgaJpZM4AchzX>
.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com
|
This way of doing things was already discussed in 2013 something and AFAICT was frowned upon as:
That's breaking semantics of the notebook (IMHO), because then the text of the "markdown" cells depends on kernel state. So while it is cute i'm going to downvote this idea. Also the I'll note that similar magics have existed for quite some time and way more advanced features than just using |
|
My thinking has evolved over time and I like @gnestor s idea.
By definition, if a user wants variables from the kernel in markdown cell,
that markdown cell will depend on the kernel. Saying "that breaks the
semantics of the notebok" is like saying we shouldn't allow code cells
because they run on the kernel and return output. One of the main purposes
of the notebook document is to serve as a record of what the kernel does.
The implementation on any kernel that support rich output is trivial and it
this break anything downstream (nbconvert, import hooks) then those things
have bugs (markdown output is already a thing).
But I am fine doing this outside the ipython kernel...
…On Thu, Apr 27, 2017 at 10:29 AM, Matthias Bussonnier < ***@***.***> wrote:
@Carreau <https://github.com/Carreau> Any interest in something like this?
This way of doing things was already discussed in 2013 something and
AFAICT was frowned upon as:
- you need to reimplement %%markdown in every language
- it requires computation on kernel side to display text
- it changes the semantic meaning of rendering a markdown.
- screw-up nbconvert --to markdown and nbconvert --to script
- screw-up notebooks import hooks.
That's breaking semantics of the notebook (IMHO), because then the text of
the "markdown" cells depends on kernel state. So while it is cute i'm going
to downvote this idea.
Also the %%markdown, %%latex, %%javascript ... etc magic were written at
the time when we were having this discussion.
I'll note that similar magics have existed for quite some time
<https://gist.github.com/bj0/5343292> and way more advanced features than
just using %%markdown, so please don't rush because you'r exited as
you've never encountered this idea before.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2958 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABr0HU-Gb3ENSidykbte53geYqPpy-sks5r0NCAgaJpZM4AchzX>
.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com
|
|
Reference implementation (classic notebook extension): https://github.com/ipython-contrib/jupyter_contrib_nbextensions/blob/master/src/jupyter_contrib_nbextensions/nbextensions/python-markdown/main.js |
Just clarifying since I initially read your statement wrong - this is using the kernel to display markdown (as a markdown mimetype), not to render markdown to html. The actual rendering markdown to html is still being done on the client side, in nbconvert, etc. I like this approach. If you want easy markdown that involves kernel state, then use the kernel to display that markdown. If you want that markdown to update live, then use a widget (you could use an OutputWidget, or we could make a MarkdownWidget similar to the HTMLWidget). This, accompanied with easy ways to hide/show input and output, makes a lot of sense to me. |
|
Just came across this ticket and would like to mention that SoS also took the aforementioned approach, namely rendering markdown from the kernel. Basically, sos implements a |
|
Here is a simple fix: jupyter/nbconvert#320 |
|
It would be nice if whatever happens can also be compatible with RMarkdown. That uses The value of x is `r x`. Where |
|
https://github.com/vatlab/markdown-kernel is not necessarily what you need but it supports Rmarkdown cells in a Jupyter environment. |
|
TL;DR: is this thread still up-to-date? JupyterLab has no direct solution, but Notebook does? (2020) So ... reading this thread, and trying the various hacks suggested ... it seems that as of 2020 this feature is still impossible/missing in JupyterLab (which the main site has been pushing people to use for several years now?), unless you use SoS (all the other workarounds seem to be either notebooks-only i.e. legacy/useless for modern installs ... or require throwing-away most of the convenience of using Jupyter's "code + markdown" core functionality). Is there something I've missed? It seems like the main JupyterLab (note: not Notebooks, which work fine, and I feel a bit betrayed that the main project pushes Lab so hard when Notebooks clearly work a lot better, even now in 2020) essentially doesn't support markdown in docs for anything beyond trivial, non-analysis, examples - rhetorically speaking: what's the point of including a formatting system in a data analysis product if you can't output your data with the formatting? This seems so wrong that I think I must have missed something basic. "SoS + markdown-kernel" feels like a sledgehammer to crack a walnut, but since it works ... |
|
Reading this thread, I am not sure this feature is likely to be implemented in Jupyter Lab or not. |
|
Is this dead? What is the reason we can not just reference it in a similar style as knitr? |
|
Closing as this issue is not in IPython itself and if still problematic and relevant should be opened on the right repository if this is an actual bug or code proposal. For general help use discourse. This will allow to keep the number of opened issue on the IPython repo under control and allow you to get faster response. |
|
To give some specific references on where the discussion continues:
|
and others
In PR #2592 @Carreau has come up with a syntax for referencing Python variables in Markdown cells. It uses the Jinja style
{{x}}syntax. We love this idea, but there are some things that have to be worked out:{{}}The text was updated successfully, but these errors were encountered: