[IPython-dev] [sympy] Re: using reST for representing the notebook cells+text

Brian Granger ellisonbg at gmail.com
Wed Feb 24 11:48:06 EST 2010


[Happy to get a lively response]

> The problem with transferring this to Python is that Mathematica's
> language is a very Lispy one. ExpressionCell[] contains the actual
> expression, not a string representing a Mathematica expression. You
> can't do that with Python. You would have to put the Python code into
> strings.

Absolutely....almost.  You are right that the Notebook, Cell, etc. in
the Mathematica
notebook format are full Mathematica expressions.  But, to represent Mathematica
code, they use strings:

Here is a simple "a=10" input cell:

Cell[BoxData[
 RowBox[{"a", " ", "=", " ", "10"}]], "Input",
 CellChangeTimes->{{3.4759886492031307`*^9, 3.475988649761156*^9}}]

The reason (I am guessing) that Wolfram did this is that the Notebook
lives in the
frontend, the "code" (a=10) lives in the kernel.  Thus it doesn't make sense
to "instantiate" the code into a full expression until it is in the
backend.  Which is
*exactly* how this would work in Python/IPython.  By this, I mean that
the internal
representation of "code" in IPython is a string.

> You just have a "dumb" tree structure with text leaf nodes.

At some level I agree with you.  You would have a tree in Text, Input,
Output cells
that simply have plain text leaf nodes like Text("Here is the text").  But that
does not mean that the Cell and Notebook objects could not have powerful APIs
for working with these cells.  Things like:

* Representation (reST, HTML, latex, etc.)
* Insert, delete, move, etc.
* Get all the strings of python code to execute and inject their outputs.
* Whatever else you need.

Because the Notebook would live in the frontend, it would *not* contain
methods for code execution.  But it could have an API for working
with objects that interface with the kernel.

> At that point, you might as well use XML to describe the exact same
> structure. With XML, you can push it across to other languages,
> JavaScript being the hugely important player here. Certainly, you are
> going to have a Python API that will represent that tree of text nodes
> as Python objects, but I just don't see the point of making the repr()
> of that be the lingua franca format of the notebook file. It's just a
> wasted opportunity.

Again, I think the biggest issues with XML are:

* No one wants to edit XML by hand.
* The result is not importable in a regular Python shell.

Obviously, reST doesn't suffer from the first of these issues, but it
does share the second (as well
as not being able to embed binary data like images.

Cheers,

Brian


> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com



More information about the IPython-dev mailing list