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

[Robert Kern]

On Wed, Feb 24, 2010 at 10:48, Brian Granger <ellisonbg at gmail.com> wrote:
> [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.

I agree, but that doesn't imply that the main text serialization of
the objects in the API should be Python code.

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

I don't want to write Python code in that tree style by hand, either.
Too many things to get wrong. I don't see anyone editing notebooks
outside of the notebook apps, honestly. Does anyone edit Mathematica
notebooks in a text editor? I don't think the success of Mathematica's
notebook is the file format; it's the notebook GUI itself.

> * The result is not importable in a regular Python shell.

<shrug> So you use a function call instead.

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