[SciPy-User] Pylab - standard packages

Almar Klein a.klein@science-applied...
Fri Sep 21 20:17:36 CDT 2012

On 22 September 2012 02:43, Fernando Perez <fperez.net@gmail.com> wrote:

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

Arg, I suppose we're both reacting too fast and talking interlaced :)   -
This time I refreshed before I posted :)

Ok, so we actually agree on a lot here, and I get the feeling we're
differing in opinion about subtleties...

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

So if I understand correctly, you want to put the concept of the notebook
into pylab. Kind of based around the open protocols so that different tools
can get a similar user experience.

Well, it is sticking to that approach *in pylab* :)  Obviously users
> are, have always been, and will always be, free to add any tools they
> want to their personal workflow.

Trying to get at the subtleties...  so what if IPython with notebook
feature* is a part of the base. So that every user with a pylab-compliant
distro can fire up a notebook. But, distros can (and will) ship
additionally an IDE (like IEP or Spyder) that does *not* have IPython or a
notebook-like interface, but these interfaces are still considered
Pylab-compliant. That does sound reasonable?

* What exactly are the extra dependencies for that?

> But no worries, I've ranted enough and won't push further, as I've
> made my arguments as clearly (or madly) as I can.  If people don't
> want to do that, it's fine.  We'll continue building those tools from
> our side regardless.  I just wanted to leave the imprint of a lunatic
> in the discussion, and I think I've succeeded at that ;)

Not a lunatic at all. I think this discussion is very useful. I like (most)
your ideas, but I just want to protect some things that I care for.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-user/attachments/20120922/7131f100/attachment.html 

More information about the SciPy-User mailing list