[SciPy-User] Pylab - standard packages

[Nathaniel Smith]

On Sun, Sep 23, 2012 at 9:09 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> On 23 September 2012 20:42, Nathaniel Smith <njs at pobox.com> wrote:
>> Then we should talk to the EPD folk about whether that can be fixed.
>
> Certainly. But if they disagree (it would be a big expansion, and they
> offer a more complete commercial version), we needn't completely
> revise the standard to accomodate that.

Right, but we should figure that out based on conversation and
figuring out the exact trade-offs involved. It might be worth cutting
back the spec slightly, if that turned out to be the difference
between a useful spec and wishful thinking. Especially if they had a
good reason for whatever came up, like Python(x,y) does. You wrote we
"shouldn't relax the standard"; I'm saying we should reserve our
judgement for now. I doubt we'll *need* to relax the standard anyway,
but if you want people to feel involved in something you have to make
clear that their input matters, not rule things out up front.

>> And then in the next sentence I also mentioned that there's no value
>> in telling people to do things that they won't do...?
>
> I hope that including a newer version of IPython is something that
> Python(x,y) *will* do. This is the intermediate point you were
> describing: not something that everyone already has done, but
> something that we can reasonably expect people to do.

I think this is a misunderstanding. The intermediate point I was
talking about was the one where they change what they do *because* of
discussions/a spec/etc. That's what I was addressing when I wrote:

| the only reason that I know for why the notebook wouldn't
| be supported by any pylab-relevant distro is the technical
| incompatibility between new ipythons and spyder. I assume that
| notebooks will be supported by Python(x,y) iff that is fixed. This
| seems like a low impact area for pylab to me, because I don't see how
| putting something in a spec will make any difference. The way to make
| an impact here is to go fix that code.

Actually if anything it looks like the opposite -- right now it's you
and Fernando et al who are actively interested in IPython's role in
the spec, not the spyder folks. So keeping the notebook out of the
spec for now will motivate you guys to go get that code fixed :-).

I'm sort of joking, but only sort of...

> I'm taking a longer term view: Pylab needn't be a description of the
> userbase on the day it launches. Many users don't use a Python
> distribution, so there's almost no minimum set of packages you can
> assume people have installed today. But with plenty of communication
> and elbow grease, I hope that in, say, 6 months, the idea will have
> enough traction with users and distributions that you can write code
> and say "runs on Pylab 2.0", and users will either have it or be able
> to get it easily.
>
> We're certainly not insisting that distributions implement the spec at
> once, but we're giving them a (fairly reasonable, I think) set of
> targets to work towards. Some distributions already meet it, others
> may need to update a package or two.

The way you get traction is by getting the relevant people involved in
the decision-making, and making it as useful as possible on day one.
We don't want to "give them targets", we want to work *with* them on
common goals. There's no reason we can't start with a reality-based
spec and then try to improve it. The nice thing is that the way you
improve a reality-based spec is to improve reality, so even though the
spec itself is just a webpage somewhere, it encourages changes that
matter.

What do you think of this suggestion from above?: "start a pylab list,
move the discussion there, and make sure that the various stakeholders
are specifically invited"?

-n