[FWD] Re: [IPython-dev] questions about the notebook interface

[Fernando Perez]

>>From: Hans Meine <meine at kogs1.informatik.uni-hamburg.de>

>>I just want to stress the part of "the notebook interface" that is of greatest 
>>importance to me, since most of these discussion did not seem to be concerned 
>>with it:  The interactive programming aspect.
>>
>>Actually, I don't care much about the final layouting; the biggest feature of 
>>a "notebook interface" in my eyes would be that I can incrementally write and 
>>debug a program, correcting my mistakes and ending up with a "clean history".
>>
>>Right now, ipython is the best environment for my work, but I have to manually 
>>extract "good" code fragments.  The most important thing in my eyes would be 
>>a possibility to edit and re-run my code without *appending* to the history, 
>>but just correcting and extending the existing "In [xx]: " paragraphs.  That 
>>would be especially handy in combination with loops, too.

Indeed, the interactive aspect is pretty dear to my heart (I wouldn't have 
spent all this time developing ipython if I dindn't care about that :).  And I 
think that Tzanko has a good shot at making headway pretty quickly on this 
front with ipython+pycrust.  A while ago I tried to embed ipython in IDLE and 
pycrust; while it didn't quite work, it seemed to me like the remaining 
problems were easy to solve.  It needs a bit of time, since the right solution 
(a quick hack could be done in a few hours) should involve some code 
reorganization.

>>
>>Maybe I should propose developing / collecting proper user stories first, then 
>>you could decide on their priorities and start creating solutions for 
>>existing problems (there may well be people focused on layout, which could 
>>give another user story).
>>
>>Some short user stories(*):
>>------------------------------ >8 snip 8< ----------------------------------
>>I am planning to analyse a multidimensional data structure.  I am writing a 
>>loop, collecting data but then realize that I need to initialize a variable 
>>*before* the loop.  In ipython, I can only cancel the current edit, type the 
>>initialization and fetch all lines from the history (or retype them) 
>>one-by-one.  What I'd like to be able to do is to just press cursor up, 
>>insert a line, and continue further down, then execute the whole loop.

Yup, this is really annoying.  For much of this, Xemacs+ipython.el can be a 
better solution, as you can keep a scratch.py buffer where you do multi-line 
edits, and run them in the ipython buffer with C-c C-|.


>>I successfully analyzed some data derived from images.  Now I want to change 
>>some preprocessing parameters and re-run the analysis.  Again, I want to 
>>insert / change some code at the beginning and re-execute several blocks of 
>>commands that use the now changed variables.

This one is already doable in ipython: just call

macro mm 12:30 34 39:50

and then typing mm is like re-executing all those lines.  All code is executed 
clean, so variable changes are recognized:

In [1]: print 'x is:',x
---------------------------------------------------------------------------
exceptions.NameError                                 Traceback (most recent 
call last)

/usr/local/home/fperez/<console>

NameError: name 'x' is not defined
x is:
In [2]: x=99

In [3]: macro mm 1
Macro `mm` created. To execute, type its name (without quotes).
Macro contents:
print 'x is:',x

In [4]: mm
Out[4]: Executing Macro...
x is: 99

In [5]: x='hi'

In [6]: mm
Out[6]: Executing Macro...
x is: hi

See macro? for further details.

>>It would be useful if some sort of dependency graph could be generated.  E.g. 
>>when I change a "cell" (piece of code) which (re-)assigns variables, all code 
>>fragments (cells) that depend on these results (use that variable) should be 
>>marked as "dirty".  Automatic execution of these cells should not be the 
>>goal, since that could be unwanted by the user, need a long time, and/or 
>>destroy/overwrite precious results.

Very ambitious, but an idea worth keeping in mind for the future.

>>For image processing purposes, I want to be able to have image objects that 
>>result from python expressions shown as embedded images in the notebook.
>>
>>Similarly, I'd like to have graphs (e.g. from Gnuplot.py) be embedded in the 
>>notebook.

My current favorite idea is for the notebook format to have some kind of 
include directive like:

markup.graphic('foo.png',options...)

Once a fancy GUI is up and running which can display text and inline graphics, 
they could be shown on-screen.  But at least rendering them to PS/PDF should 
be easy.  Note that the GUI for this is not trivial: I think that only Qt4 
(released yesterday) has a rich text widget with inline graphics support.  I 
may be wrong, but I think that none of the text widgets in GTK, Tk or WX have 
this capability.  That's why I'm concentrating on having proper backend 
support for now, along with  a basic GUI which can at least display the text 
parts and provide the interactive support.

This would give us the possibility to:

1. Edit the notebooks 'by hand' with plain editors, even if interactive 
support isn't there.

2. Have a gui with interactive support that can provide the ability to re-edit 
the same input group multiple times without re-generating new input cells.

If both systems can operate on the same files, one could switch back and forth 
between the editor and the interactive environment, depending on the task at 
hand (heavy-duty coding or multiple tests).  This might even allow a system 
like Mozilla's composer (now Nvu), which has both a WYSIWIG tab and a raw html 
tab for the same document, and one can switch back and forth between them.

>>A friend of mine wants to be able to write longer Mathematic-like notebooks, 
>>and needs proper namespacing for chapters/sections, so that variable names 
>>can be re-used.

This can be done by issuing a 'del' statement at the start, much like in 
Mathematica you need to call Clear[] on symbols.

>>------------------------------ >8 snip 8< ----------------------------------
>>
>>Actually, the xemacs approach seems to be promising to me, I am looking 
>>forward to further information / results / input.

Thanks for your input!

Best,

f