[IPython-dev] Re: notebook composition UI thoughts

[Hans Meine]

On Wednesday 06 July 2005 22:34, Fernando Perez wrote:
> This is mostly a confirmation of Robert's position.  Module-per-cell,
> multiple-interpreters, auto-dependency analysis, etc. are all potentially
> worthwhile ideas for certain contexts, but certainly not for a first shot.

Point taken and agreed.  Still, I'd like to have a "future works" section in 
this discussion and the Wiki. ;-p

> If we can get an interactive environment which enhances the ipython
> command-line experience with full-screen editing (to address the problem of
> endless appending to a session), and basic functionality for supporting
> rich-text documents (even if not rendered directly in real-time in the
> working window), we'll have a useful system for many of us.

Believe me, I am looking forward to it.

> I should note that things like automatic dependency analysis are
> notoriously difficult (I'd actually guess nearly impossible) in python. 
> The language is far too dynamic for that, and this is _exactly_ the same
> problem which has made all restricted execution systems for python fail (to
> the point where they've been removed from the standard library). [...]

You're right, it's difficult, but I am not taking the rest of your arguments; 
I think that our notebook interface is very much different from a restricted 
execution system, in the sense that it's feasible to just tell the user 
"don't use import-in-an-eval, but just clearly write it out as an 
unconditional statement (maybe even at the beginning of the cell), if you 
want it to work".  Some users *want* it to work, and it's no big restriction 
to use import w/o exec or eval.

> It is true that in mathematica, the top-down flow of the text can be
> misleading, as the time-flow of execution (only recorded by the prompt
> numbers) is what really defines the in-memory status of the kernel.

Furthermore, it's about saving and re-executing a freshly opened notebook if I 
understood that correctly.  That is doable with a stored execution order, and 
important IMO.

> There 
> are systems with automatic dependency tracking and recalculation:
> spreadsheets like excel do this, as well as systems like Mathcad.  But
> those systems have much more limited assignment semantics than python, so
> they can keep such a dependency tree consistent at all times with
> reasonable effort.

Oh, these systems often also contain eval-like things, sometimes even allow 
(indirect) cyclic references, and often their dep. analysis fails.  However, 
I still find the basic analysis very useful.

> I'd rather not provide such a system if it is going to have random
> reliability.

It's not really "random", right? ;-)  Then I wouldn't like to have it either.

> That's been exactly the position of python-dev on restricted 
> execution: since we can't guarantee it will work, and it can break almost
> anywhere, we simply won't ship it (until someone can come along with a
> solution shown to be robust).

This is very much understandable because it's about security, but IMO that's a 
different world/topic.  I probably would not develop critical 
spaceship-controlling software in any kind of IPython notebook sessions. ;-)

> On the multiple interpreters front, that's more likely in the near term.
> There's a good possibility that the gui will be built with the ipython
> 'kernel' living in a separate process, to allow it to be restarted without
> destroying the gui.

We did the same in our own "PyTerm", but mainly to make Ctrl-C work.

-- 
Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo