[IPython-dev] Re: notebook composition UI thoughts
hans_meine at gmx.net
Wed Jul 6 15:51:37 CDT 2005
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
> 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
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.
/ / ANS ooo
More information about the IPython-dev