[IPython-dev] ipython notebook installation instructions

[Brian Granger]

On Thu, May 31, 2012 at 11:56 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, May 31, 2012 at 11:49 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>> I think there are some other issues we have to be careful about:
>>
>> * Implementing it purely in the kernel would possibly break the
>> terminal and qtconsole as they rely on input splitter to make
>> decisions for the frontend.  Our transformation pipeline is actually
>> quite complex in that code goes through multiple passes of the input
>> splitter for static transformations and then the prefilter for dynamic
>> ones.
>
> Not quite:  these clients actually instantiate their own inputsplitter
> object, so they are using the same *library* as the kernel, but not
> the same *object*.  What this does mean is that if somebody implements
> a kernel with highly customized input logic, they can't expect the
> default IPython clients to play nicely with it, they will need to also
> write custom clients.

Yes, the input splitter on the frontend side will have to be
configured in the same way as the one on the kernel.  If the frontend
and kernel are running different hosts, that is problematic.

There is another aspect of this.  The ability of the input splitter to
work properly depends on a very fragile set of regular expressions and
line by line state.  I am not sure if it is possible to get all of
that to work while simultaneously allowing 1) arbitrary text in cells
and 2) arbitrary transformations of that text.  It is possible we
could get this to work, but I am not even sure it can be done in a
consistent way.

I think the idea of putting these things in the kernel might make
sense, but to play devils advocate for a second...

Another reason to have this in the frontends.  If someone writes a
notebook, and that notebook has R syntax in all of its cells, that
notebook won't run on anything but R-transforming kernels.  When an
Python notebook runs on an R kernel, or vice-versa, you will get
confusing SyntaxErrors.

This requires a separate notebook server or kernel manager for each
such type of notebook.  What happens when I have users that have R
notebooks, Matlab notebooks, etc., etc.  You end up with an incredibly
difficult situation to manage, both for users, the person running the
notebook server and the developers of the notebook.  I think the
reality is that most users will want to switch back and forth between
different syntaxes.  We need to make that simple, easy and lightweight
and I don't see how to do that with a kernel-side approach.

> But that seems fair to me: if you deviate a lot from the default
> semantics and you're working with a system that has both clients and
> servers, you need to ensure your new semantics are handled
> consistently everywhere.
>
>> * This further opens the door for the notebook to support other
>> languages.  People will want things like tab completion, syntax
>> highlighting, tooltips, etc to work.  This will require some very
>> careful thinking because I am not sure we want to make IPython fully
>> multi-language aware.
>>
>> This is really important though and we need to think about these things.
>
> Yes, the multi-language support does open some pretty delicate issues
> from the client side, if we want to do it system-wide.  With custom
> cells like we have right now with Cython and R the problems aren't too
> severe (though already tab completion and highlighting will be wrong
> in those cells), but if we want to do it system-wide, it will indeed
> require some very careful thought.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com