Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JEP: official support for Markdown-based notebooks #102

Open
avli opened this issue Mar 25, 2023 · 1 comment · May be fixed by #103
Open

JEP: official support for Markdown-based notebooks #102

avli opened this issue Mar 25, 2023 · 1 comment · May be fixed by #103

Comments

@avli
Copy link

avli commented Mar 25, 2023

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.

@ManPython
Copy link

ManPython commented Jul 26, 2023

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

  1. 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
  1. Whole idea is about reflection to cells as internal in file, then option to control cells inside code as some tigers.
  2. 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.

@fcollonval fcollonval linked a pull request Jun 12, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants