[IPython-dev] Re: notebook composition UI thoughts

[Fernando Perez]

Hans Meine wrote:
> 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

As Robert indicated, by all means please post these ideas there.  Once we get 
a proper ipython wiki (the tools are being currently installed) I'll take care 
of migrating the material over.

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

I dislike half-working stuff.  For example, ipython has a dreload() command, 
which tries to do 'deep reloading', to properly update a module chain.  This 
code wasn't written by me, it's tricky and uncommented, and it came as part of 
one of the original projects I merged into ipython when I started.  I have 
received singing emails of people saying 'dreload() rocks, I'd use ipython if 
only to have access to it, etc.'.  And yet, I hardly publicize it, and I don't 
let it override the default reload() command (which it used to do in the 
original LazyPython).  The reason is that I've seen it fail in subtle cases, 
and I've received reports of puzzled users about its behavior.

Since I haven't taken the effort to fix it (I tried once, and failed), and in 
general it can't be 100% fixed (extension modules can't be reloaded as far as 
I know, regardless of what tricks you play), I keep it in a dark corner.

The moment you make a feature reasonably central to a framework, it HAS to be 
as robust as humanly possible.  Because people _will_ find ways of breaking 
it, either directly or because of third-party code they may be using which 
does funky things.  So I am very, very reluctant to put in a feature such as 
this, which I know is basically impossible to make really 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. ;-)

Well, you should talk to Frederic Mantegazza: he uses ipython as the control 
console for the largest neutron scattering source in Europe (at the Institut 
Laue-Langevin in Grenoble) :)

Cheers,

f