JEP: official support for Markdown-based notebooks
avli opened this issue · 1 comments
Backgound
During the Jupyter Notebook workshop, it was decided to attempt to address a couple of issues associated with the .ipynb
format, such as:
- VCS-unfriendliness.
- Human readability/writability.
- Accessibility to standard text processing tools.
- Lack of syntax for existing narrative-centric text-based formats for embedding/referencing cell outputs.
Proposal
The JEP will propose an alternative Markdown-based serialization syntax for Jupyter notebooks to be adopted as an official standard by the Jupyter community and describe steps to make it supported by most tools in the ecosystem. The format will allow the lossless serialization from/to .ipynb
, be reasonably human readable, and be more VCS-friendly.
Examples
Example of a minimal Jupyter notebook as a Markdown file:
---
metadata:
kernelspec:
display_name: Python 3 (ipykernel)
language: python
name: python3
---
# A minimal Markdown Jupyter notebook
This is a text cell
```{jupyter.code-cell}
1+1
```
This is another text cell
+++
And another one
A more sophisticated example can be found in this repository.
Regarding 2 issues about "Bad case", I think that MD format can be in simple var or class like:
- string
j.cell = "# A minimal Markdown Jupyter notebook
This is a text cell
"
j.cell = 1+1
Then j.cell just can be hidden in notebook by special addon in options. And reason for list of all cells replacement can be like:
j.cell[0] = "# A minimal Markdown Jupyter notebook
This is a text cell
"
j.cell[1] = 1+1
a) or simple in configcell
can be assigned as jupyter class cell = j()
or cell = jupyter()
b) then simple enhancement to hide from j.cell[0]
to j.cell[1]
and j.cell[x]
etc
c) issue around \newline
https://www.markdownguide.org/basic-syntax/#line-break-best-practices
- Due proposal to make a
cell
as class from jupyter then this var can be decoreted I think as@jupyter
cells = [
{
"cell_type": "code",
"execution_count": 11,
"metadata": {},
"outputs": [],
"source": [],
"widgets": [], # more vars to control jupyter
"jupyter_class": ["j"], # class to reserve for jupyter decorator
"jupyter_cell": ["cell"], # var to reserve for jupyter notebook (to make hidden)
}
from ipyleaflet import Map, WMSLayer, SearchControl, Marker, AwesomeIcon ,ScaleControl, FullScreenControl, basemaps
j.cell[1] = 1+1
cell[1] = 1+1
j.cell[2] = 1+1
cell[2] = 1+1
- Whole idea is about reflection to cells as internal in file, then option to control cells inside code as some tigers.
- Ayway.. I think is no sense to parse python code from "" as json eg.
"1+1"
- Jupyter can take any line as cell if exist any string, then can be a vision for reflection for code without "" as code default.
It's should be taken from default philosophy of IPython cmd line policy - in case no assign array id/index then jupyter can do this, and the main role is to hide this as a paper notebok to export as pdf, etc. and input cell vision, in fact that doesn't matter how file looks, but.. (cod not as string where hard to edit
text = raw_input("prompt") # Python 2
text = input("prompt") # Python 3
Anyway.. it's better to have python object than json
Complicated? Noo..
Coz if "cell_type": "markdown" then just decorate it thas is not @cell
but @md
or @MD
There is no children/root in json .ipynb but stack down execution, json doing some complication due "pretty code" and it is far from python convention as indention.
For sectors as "cell_type": "markdown" exist quoting string, then no difference about assign var for json or as python object.
Soo...
Jupyter need change policy around:
outputs = cell output
source = cell input
Even this can be more interactive, then
outputs = cell output with assigned class as attachments
eg.
@source
j.cell[2] = "x = 1+1"
@outputs
cell[2] = 2
@source
plotly = "x"
@attachment
cell[3] = "chart = plotly"
Of course need virtualize cells as lines.