[SciPy-User] Pylab - standard packages

Fernando Perez fperez.net@gmail....
Fri Sep 21 19:43:16 CDT 2012


On Fri, Sep 21, 2012 at 5:11 PM, Almar Klein <a.klein@science-applied.nl> wrote:
> Fernando, I enjoyed your rant and think you make great points (although I
> don't see why a notebook in an IDE would not be able to work as good as from
> a browser).

Oh, it does! Here's the Emacs implementation, with lisp websockets and all:

http://tkf.github.com/emacs-ipython-notebook/

And right now the web server is necessary but that's an implementation
detail, one could write something that speaks zmq directly to the
kernels, without any http traffic at all.  That would be trickier to
use remotely, but it would be a perfectly sensible local
implementation of an IDE client.

>> - *not* putting *a* notebook system into the spec is a mistake,
>> - if one is going to go in, the ipython one is the sensible choice.
>>
>> Of course, the overall community may disagree and decide that they
>> want pylab to be a spec that stays bounded by the 'shell + editor/ide'
>> idea.
>
>
> The community should not decide anything about what interface the user
> should use. By all means, let that be the choice of the user! I think the
> question for Pylab is not "do we, or do we not go notebook-style". It's
> about specifying base packages. And later maybe documentation, packaging
> etc. I really like IPython's idea of the notebook. And if you're right about
> them being the future, their popularity will surely grow over time. But
> let's not force that on our users right now.
>
> As I said earlier, I have no objection of including IPython in the base
> packages. But I do have an objection against picking one interface and
> saying that is *the* one. If IPython is to be included it should be for the
> reasons Thomas indicated; to have something usable that's always there and
> on which all the tutorials are based.

Actually, I don't really care about the interface.  What I care about is:

- the format, which is open and which is what will have archival
value.  there's nothing ipython-specific there, and in the future
hopefully not even *python* specific (we want to use it for R, matlab,
etc).

- the protocol, which we've also specified openly and can be
implemented by others (sage already uses it in their new work).  It
has some python-isms but they are cosmetic and should be trimmed out
over time.

The emacs client above is an example of a third-party notebook client
built for users who'd rather use emacs than a browser.

*That* is what matters to me; the ipython implementation of the above
two things can be thought of as a 'reference' implementation,
Takafumi's EIN is another one, and there could easily be more.

And BTW, I've never thought of saying "let's only introduce people to
a notebook approach", far from it.  The shell is too useful, robust
and important a tool not to start there and have it as the base point
for everything.

My take is that if we want pylab to be a forward-looking platform for
modern scientific computing, it should include a notion of a notebook
system from the get-go, like Mathematica did 20 years ago and Sage 6
years ago.  It doesn't have to be the ipython UI, that's for sure:
Spyder could have an awesome Qt client, for example, similar to how
the Emacs one was implemented.

Human-facing UI layers are indeed deeply personal, and what for some
is perfect for others is intolerable (I know the lack of solid vim
editing in a browser drives many people mad in the sage/ipython
notebooks, for example).

I see a chance for a format and a protocol to have an impact (and I
haven't heard of any alternatives).  But again, one vote out of many,
etc.  I'll go back to writing the last of my grants instead, so that
we actually have funding to make this happen regardless of what pylab
decides ;)

Cheers,

f


More information about the SciPy-User mailing list