JEP: official support for Markdown-based notebooks

[avli]

Backgound

During the Jupyter Notebook workshop, it was decided to attempt to address a couple of issues associated with the .ipynb format, such as:

1. VCS-unfriendliness.
2. Human readability/writability.
3. Accessibility to standard text processing tools.
4. 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](https://github.com/stevejpurves/jep-text-based-format-example).

[ManPython]

Regarding 2 issues about "Bad case", I think that MD format can be in simple var or class like:

1. 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

2. 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

3. Whole idea is about reflection to cells as internal in file, then option to control cells inside code as some tigers.

4. 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.