[SciPy-User] Pylab - standard packages
Wed Sep 19 06:35:08 CDT 2012
On 19 September 2012 11:21, Joe Harrington <firstname.lastname@example.org> wrote:
> BUT if your package is in PylabTM and your competition isn't, you have a
> *big* advantage. You'll get installed by every Linux distro, and the
> computational Python distros will want to be in compliance as well, so
> you'll show up there. Regardless of intent, if the community makes this
> a standard and a distro does not follow it, it will look strange:
> tutorials written to the Pylab standard will not work with that distro,
> commonly shared code will not run in it without add-ons, etc. So,
> distro maintainers will want to be in compliance if they can be. By
> choosing among packages, Pylab will stifle competition, regardless of
> our pure intent.
Inevitably, yes, we reduce competition to some extent. But I'm not
sure this is such a bad thing: we want there to be 'one obvious way to
do things'. Having a lot of alternatives can be confusing for users,
and it can fragment developer effort, so none of the alternatives are
as good as they could be.
Of course, we don't want to suppress competition too much -
alternatives can try valuable new ideas and add features that would be
difficult in the standard packages. The standard wouldn't stop people
installing alternatives, or distributions from including those
alternatives as well. That we specify matplotlib as standard doesn't
stop anyone using Chaco, Mayavi or Visvis. And the standard will be
versioned, so if in a couple of years a new package has become
indispensable, we can add it to the standard.
> Make the set only include packages for which there is essentially no
> competition. numpy+scipy+ipython+binary file formats?
That's tricky to define. Depending on who you ask, for example,
IPython has several competing projects. And if a new competitor to
Numpy were to emerge, would we avoid taking sides, even though our
whole stack depends on Numpy? We even limit the choice for Python
itself, by requiring packages that use the C-API.
We have to take sides in some debates - not as a partisan move to
bolster our favourite projects, but so that users get a coherent stack
of useful tools. Useful tools have competition, and we can't say every
alternative is important.
As an aside, you refer to 'binary file formats' - is there a
particular project for working with those that I should be aware of?
> 3. Define several levels of Pylab:
And now we're up to 4 levels, I see. That's too complex. I feel
strongly that if we're going for multiple levels, it should be no more
than 2, at least for now. And even for the more inclusive one, I don't
want to build a kitchen-sink specification that includes a big list of
packages. That's for distributions to define, not the standard. As I
mentioned before, I think we need simple descriptions of 'why you want
> Level 1: Stuff needed for beginner tutorials, Numerics 101 classes, etc.
What 'beginners' need isn't necessarily the base of the stack, though.
In fact, more often than not, beginners use high-level packages, and
you learn about the stuff lower down the stack as you move on. And the
needs of 'beginners' might be very different in different fields. In
biology, we begin with statistical tests, not array manipulation.
Also, hard drives are large and University internet connections are
fast - why shouldn't a beginner just download the more inclusive
'recommended' level, and leave some parts unused?
I'm focussing on the user here. I don't want to define multiple levels
just to push the tricky decisions about inclusion downstream to
distributions and users. If the standard is to have multiple flavours,
we need a clear story about how it benefits users.
> Finally, I think that there should be installers.
Sorry, this is not part of my plan, at least for now. Maintaining a
distribution for several different OSs is a much bigger task, and it's
not one that I want to take on. I'm optimistic that existing
distributions will meet that need.
Also, I intend the name Pylab to mean a particular set of packages,
however you've installed them. If we make a Pylab distribution, it
gives the impression that EPD, for example, is not Pylab. Then we'd be
back in the current situation, but with one more Python distribution.
More information about the SciPy-User