Show More
@@ -3,7 +3,11 b'' | |||
|
3 | 3 | =============================== |
|
4 | 4 | |
|
5 | 5 | This document serves as a sample/template for ideas on how to store session |
|
6 |
data on disk. This stems from discussions we had on various mailing lists |
|
|
6 | data on disk. This stems from discussions we had on various mailing lists, and | |
|
7 | should be considered a pure work in progress. We haven't settled these ideas | |
|
8 | completely yet, and there's a lot to discuss; this document should just serve | |
|
9 | as a reference of the distilled points from various conversations on multiple | |
|
10 | mailing lists, and will congeal over time on a specific design we implement. | |
|
7 | 11 | |
|
8 | 12 | The frontend would store, for now, 5 types of data: |
|
9 | 13 | |
@@ -50,3 +54,58 b' The non-text cells would be stored on-disk as follows::' | |||
|
50 | 54 | :id: 3 |
|
51 | 55 | |
|
52 | 56 | sh: askdfj: command not found |
|
57 | ||
|
58 | Brian made some interesting points on the mailing list inspired by the | |
|
59 | Mathematica format, reproduced here for reference: | |
|
60 | ||
|
61 | The Mathematica notebook format is a plain text file that itself is *valid | |
|
62 | Mathematica code*. This id documented here: | |
|
63 | ||
|
64 | http://reference.wolfram.com/mathematica/guide/LowLevelNotebookProgramming.html | |
|
65 | ||
|
66 | For examples a simple notebook with one text cell is just:: | |
|
67 | ||
|
68 | Notebook[{Cell['Here is my text', 'Text']}] | |
|
69 | ||
|
70 | Everything - input cells, output cells, static images and all are represented | |
|
71 | in this way and embedded in the plain text notebook file. The Python | |
|
72 | generalization of this would be the following: | |
|
73 | ||
|
74 | * A Python notebook is plain text, importable Python code. | |
|
75 | ||
|
76 | * That code is simply a tree of objects that declare the relevant parts of the | |
|
77 | notebook. | |
|
78 | ||
|
79 | This has a number of advantages: | |
|
80 | ||
|
81 | * A notebook can be imported, manipulated and run by anyone who has the support | |
|
82 | code (the notebook module that defines the relevant classes). | |
|
83 | ||
|
84 | * A notebook doesn't need to be parsed. It is valid Python and can be imported | |
|
85 | or exec'd. Once that is done, you have the full notebook in memory. You can | |
|
86 | immediately do anything you want with it. | |
|
87 | ||
|
88 | * The various Notebook, Cell, Image, etc. classes can know about how to output | |
|
89 | to various formats, latex, html, reST, XML, etc:: | |
|
90 | ||
|
91 | import mynotebook | |
|
92 | mynotebook.notebook.export('rest') | |
|
93 | ||
|
94 | * Each individual format (HTML, reST, latex) has weaknesses. If you pick any | |
|
95 | one to be *the* notebook format, you are building those weaknesses into your | |
|
96 | design. A pure python based notebook format won't suffer from that syndrome. | |
|
97 | ||
|
98 | * It is a clean separation of the model (Notebook, Cell, Image, etc.) and the | |
|
99 | view (HTML, reST, etc.). Picking HTML or reST for the notebook format | |
|
100 | confuses (at some level) the model and view... | |
|
101 | ||
|
102 | * Third party code can define new Notebook elements that specify how they can | |
|
103 | be rendered in different contexts. For example, matplotlib could ship a | |
|
104 | Figure element that knows how to render itself as a native PyQt GUI, a static | |
|
105 | image, a web page, etc. | |
|
106 | ||
|
107 | * A notebook remains a single plain text file that anyone can edit - even if it | |
|
108 | has embedded images. Neither HTML nor reST have the ability to inline | |
|
109 | graphics in plain text files. While I love reST, it is a pain that I need an | |
|
110 | entire directory of files to render a single Sphinx doc. | |
|
111 | No newline at end of file |
General Comments 0
You need to be logged in to leave comments.
Login now