[SciPy-User] Pylab - standard packages

[Nathaniel Smith]

On Fri, Sep 21, 2012 at 4:50 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> On 21 September 2012 15:39, Nathaniel Smith <njs at pobox.com> wrote:
>> I think by definition, a "pylab tutorial" would have to be one that is
>> aimed at a somewhat amorphous set of configurations (different OSes,
>> distributions, etc.), and has some other goal beyond describing how to
>> start up a Python REPL. Being able to say "start up a Pylab shell and
>> ..." will already get us quite a long way, so long as all "pylab
>> shells" are equivalent in the ways that matter for the tutorial. Being
>> able to plot matters much more than where exactly in the UI those plot
>> windows end up located.
>
> If it was as simple as where plot windows turned up, yes. But there
> are a whole host of issues from starting the interface to syntax like
> "foo?" that differ. They might seem trivial, but they're all things
> that will confuse new users going through a tutorial. So I think a
> standard interface is important.

I'm not sure how we keep talking past each other here. Let me try again :-).

What I'm suggesting is that in a "pylab" system, the default thing
that happens when you ask for a shell is that:
- you get an IPython REPL
- and also this IPython REPL has plotting mainloop integration junk
already set up for you
- and also this IPython REPL has some stuff added to its default namespace
- etc.

I just think we should remain agnostic for now about how you "ask for
a shell" -- whether that's opening an ipython notebook, or clicking
Interpreter -> New in Spyder, or whatever.

>>> P.S. Nathaniel: you describe trying to set conventions for how to test
>>> packages or find documentation, not to mention installing packages. I
>>> agree with all of that, but I'd like to put it under 'battles to fight
>>> another day'. If we're going to do anything, we can't try to do
>>> everything.
>>
>> Really I'm trying to work toward consensus on what "pylab" should mean
>> and what's in principle in scope. If we agree that these are the kinds
>> of things that pylab should stand for, then they can go on the todo
>> list until someone actually gets around to them. Anyway, volunteer
>> effort isn't a conserved quantity. Having a long todo list can
>> actually increase your chances of helpers showing up :-).
>
> I think those things are out of scope for 'Pylab', in that they
> shouldn't be part of the standard. But in doing this sort of
> integration, we will highlight those inconsistencies, and I hope this
> community will play a key role in fixing them. So by all means put
> them on the to do list, but let's not get distracted by them at the
> moment.

Can you elaborate on what you think Pylab's scope is, then? My attempt
is this quote from the original email: "Basically I feel like the main
value a 'pylab brand' can provide is by finding places where user
quality-of-life can be improved by standardizing and documenting
conventions, and then evangelizing those to package and distribution
authors." I think of Pylab as a banner for making the cross-package
overall user experience better. That certainly includes creating
standards for available packages and UI conventions, but making
documentation searchable and making it easy to install domain-specific
packages would clearly be in scope as well. But that's just my image
of what pylab could mean, you should share yours too...

-n