[SciPy-User] Pylab - standard packages
Wed Sep 19 03:49:53 CDT 2012
> I also think we should specify minimum versions.
I think Fernando proposed in the NumFocus thread to specify *exact*
version, so that you can exactly reproduce scientific results. I liked that
idea. Having said that, I think its probably best to use minimum version
first and work on exact versions once we've got the other parts of pylab
Should the standard include an interface? IPython, a more traditional
> IDE, or both? On the one hand, specifying a standard interface means
> users can share experience better, and exchange richer files, like
> IPython notebooks or IDE project structures. Matlab, for instance,
> wins praise for including a powerful IDE by default. On the other
> hand, we've got several interesting UI efforts still taking shape -
> IPython notebooks, Spyder, IEP - and declaring one standard would make
> the alternatives less visible. I'm honestly torn on this - I can see
> good arguments for and against.
I think the goal should be to share functionality. Experience is much more
subjective. By specifying a single interface you're making it harder for
users to use other/new interfaces. A lot of interesting stuff is still
going on in these areas, and I don't think there is one interface that is
as widely used as numpy is for numerics. You have a good point with sharing
of richer files, but maybe we should try keeping it easy to share code
between interfaces. In any case, I don't think it justifies selecting one
interface in the standard.
The nicety of shipping an IDE with the framework (like Matlab) is something
that should be left to the distributions IMO. Python(x,y) does that, and
we're working on something similar based on IEP.
One thing that I've liked from the start about this pylab idea, is that it
makes distributions "siblings" under one parent (i.e. the pylab standard).
It has a unifying effect, and I'm afraid that we lose that if we select one
> On the NumFOCUS list, Chris Kees raised the idea that there could be
> two or more levels of packages, e.g. 'core' and 'recommended'. I don't
> think we should add that kind of complexity in the first version, but
> keep in mind that we could differentiate it later.
I liked the idea (can't remember where I've read/heard it) that different
groups can maintain their own page with packages that are relevant to their
field. As someone working in medical imaging I would suggest skimage and
pydicom should be in the standard, but as a biologists you may not even
know what pydicom is :) So it's kind of two levels, but the second level
is partitioned in different topics.
Almar Klein, PhD
phone: +31 6 19268652
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-User