[IPython-dev] ipython notebook installation instructions

[Brian Granger]

On Thu, May 31, 2012 at 11:39 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Thu, May 31, 2012 at 10:33 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>> We have started tho think about things like that, but haven't quite
>> gotten there.  I think the main question I have is whether or not this
>> transformation should be applied by the frontends or the kernel.  The
>> problem with the kernel is that there could be multiple frontends
>> connected to the kernel and it would be very confusing for those users
>> to all of a sudden to switch modes.  Also, I don't like the idea of
>> having stateful magics like this.  We have tried that with the %autopx
>> magic is it tends to be very confusing.  I guess as I write, I am
>> leaning towards this being a frontend transformation.
>
> My thinking is actually looking a bit different right now, let me try
> to explain.  For a long time we had the notion of a user-configurable
> prefilter function, that would be given every line of input to
> transform.  That's becaue IPython didn't have a concept of cells or
> much else beyond the current line.  Sage (and others) plugged their
> syntactic transformations via this mechanism, as was intended.  It
> worked, but it's not ideal.
>
> Now that we have a concept of cells, I'd like to see all users of the
> idea of custom IPython-based environments to move to a cell-based
> approach.  The transformations pipeline is now reasonably well
> encapsulated, so we can come up with a clean API for user-defined
> transformations that work at the cell level.  Users should be able to
> define in a profile a function to be applied in the pipeline, that
> gets a cell and returns a cell.
>
> But that means that this would happen at the kernel level, not the
> client level, and I think that's OK: these would be highly customized
> kernels, and such that you'd want them to behave identically no matter
> what client you're using to control them.

Doing the transformation always for all kernels solves the nasty
stateful issues we ran into with %autopx.

> The above doesn't prevent someone from writing a client that does
> extra stuff to its input before sending it to an IPython kernel.
> Since the kernel is agnostic to the clients, people can already do
> that and we'd never know.  Someone could for example subclass our
> Qtconsole and write one that has additional transformations on all
> input typed before it sends it out.
>
> But I think that we should think up an official, clean way of updating
> the old mishmash of prefiltering transforms for future use.  Sage
> isn't the only project doing this kind of thing, so having an official
> API for it is, I think, a good idea.

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

Cheers,

Brian


> 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