[SciPy-User] Pylab - standard packages

Jason Grout jason-sage@creativetrax....
Fri Sep 21 22:59:58 CDT 2012

This conversation moves fast!  Replies inline below.

On 9/21/12 7:43 PM, Fernando Perez wrote:

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

Which also brings up that zmq is also a dependency of pylab which many 
distributions are not likely to have currently...

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

How stable is the current format?  For that matter, what *is* the 
current IPython "Computable Document Format" :).  Is it documented 
somewhere?  The best I could find was at 

It seems like there were discussions a little while ago on the IPython 
list about changing the format, or adding something to the format, or 
something.  I don't recall exactly what it was off the top of my head. 
Right now, it seems that the format is defined by the IPython 
implementation.  That's fine, but the legislation in the standard 
probably should have something a little more formalized.

> - 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 protocol is documented more clearly, I think.  But it also has been 
changing, like the top-level metadata field we added (thanks again!). 
There also have been questions about possibly having custom user message 
types.  I'd like to push that discussion further too.  So maybe it's 
time to introduce version numbers for the protocol, so we can nail down 
a specific something to talk about?

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

+1 to having a reference implementation in the spec of some sort of 
computable document format.  And +1 to having something in the pylab 
that can serve as a backend for a frontend (for example, speaking the 
IPython protocol), along with a reference frontend.

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

(codemirror apparently has vim keybindings, by the way: 

> 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 ;)

Hooray for getting grants!  I guess you're working on buying more votes :).


More information about the SciPy-User mailing list