[IPython-dev] Some new cell types for describing data analyses in IPy. Notebook

Matthias BUSSONNIER bussonniermatthias at gmail.com
Sat Jul 6 08:05:14 EDT 2013

Dear all, 

It is always a pleasure to see people making proof of concept of what
IPython can do, some have the chance to have long response, other get
through the cracks, it is often a question of chance, and I think I'm not
the only one that wished to have more time to get into theses discussion

Beeing also an academic, I do understand the frustration and the wish to have a
non-linear editing tool, I haven't been an IPython contributor for as long as
many people on the list, but I think IPython decided to take time to implement
things the correct way, and if this have to be included it should be fully

It should be thought both in the development process, but also from a user
perspective, indeed most of the person that follow and post to this list are
advanced users which are able to manipulate advance concepts. In the other hand,
majority of people using/viewing the notebook have difficulties with the fact
that cell can be executed out of order, and have issues to distinguished
frontend from kernel and so on. This of course does not prevent from making a
non-linear tool that advanced user could use now, but this will be problematic
if we don't have the right abstraction for user to progressively migrate to it. 

My personal though on Gabe demo is that the POC is great, but has not been
though enough. The idea of DAG for the structure is really interesting and I
believe that it should be pushed further. IMHO alt-cell will only allow to
represent a subset of what could be done if the notebook was a real DAG. Like
the fact that at some point you might want to do some transform on the data, or
not. and an alt-cell with `do nothing` in one step is ugly. From the UI point
of view, I've been traumatized by labView, and I hope we'll not converge toward
something like that.

From a data structure point of view, I also strongly believe that nesting cell
is the wrong approach.  We already had a discussion about on-disk structure vs
in-memory structure and cell-id, and we might think of re discussing that at
some point. One of the key point is that we want ipynb format to be as much as
possible fixable by hand if needed. My though of that would be to store the
`cells` and `cell-order` separately as respectively a dict `cell-id:cell-data`
and a `list of cell-id` it would then be trivial to change the list-of-cell-id
to a DAG, ... or to share cell across notebooks in a more complex storage
format than file (warning, be carefull with this one, it's just an idea, but

To finish, I'll join with Thomas to say that this is a fascinating idea, but
that I don't think it is the right time to include. It took many prototype of
the notebook to be at current state, and we are already removing features that
we included to early by thinking that we would need it in the future. We'll do
our best to help you, and this will give us insight of what might be needed for
future versions. 

If you can of course start an IPython Enhancement Proposal[1] that describe the needs,
goal, drawback, and list different implementation proposal and/or changes proposed to
the notebook format.

Looking forward to what will come out of theses discussions. 

[1] https://github.com/ipython/ipython/wiki/IPEPs:-IPython-Enhancement-Proposals


More information about the IPython-dev mailing list