[Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
Mon Apr 7 16:27:10 CDT 2008
On Apr 7, 2008, at 2:29 PM, Robert Kern wrote:
> On Mon, Apr 7, 2008 at 11:19 AM, Bruce Southey <firstname.lastname@example.org>
>> I think that splitting the NumPy namespace should not happen
>> within a
>> major release series because it would cause too many breakages.
>> it should be in a forthcoming release like the 2.0 series where
>> it may
>> be very feasible to have a true core functionality (NumPy), extended
>> functionality (SciPy) and specific applications (Scikits). At the
>> time, Python 3K would be fully supported because it will break
>> lots of
> I would prefer not to do it at all. We've just gotten people moved
> over from Numeric; I'd hate to break their trust again.
>> It is really nice to think about having NumPy Core, NumPy Full,
>> NumPyKits, SciPy Core, SciPy Full and SciPyKits.
> Really? It gives me the shivers, frankly.
Some random comments:
1) It seems to me that the primary problem people have with a big
flat namespace is that it makes the output of dir() long and
unusable, and by implication, that a nice hierarchical organization
would make it easier for people to find stuff. As to the latter, less
so than you might think. From what I've seen, there is no generally
agreed upon organization that all will agree to or find intuitive.
There will always be functions that logically belong to more than one
category. Ultimately, this is why flatter is better as far as that
goes. If one wants to find things by category, we would be much
better off tagging functions with categories and then building some
dir-like tool that helps display things in that category. Some have
already alluded to that (Joe Harrington I believe). The only thing
namespaces solve is name collisions imho. I don't believe that the
current numpy has too many names in its basic namespace, and it
already has split out some things into subpackages (fft, random,
linear algebra) that have such a potential.
2) Some may feel that the combination of "from numpy import *" with a
lot of names makes it hard to see other things in your namespace.
True enough. But no amount of winnowing is going to keep the
namespace at a point that isn't going to overwhelm everything else.
The answer is simple in that case. If that's a problem for you, don't
use "from numpy import *". Or perhaps another dir-like tool that
filters out all numpy/scipy/pylab... items.
3) Some don't like the bloat (in disk space or download sizes) of
adding things to numpy. In my case, as long as the addition doesn't
make installations any more difficult I don't care. For the great
majority, the current size or anything within an order of magnitude
is not an important issue. For the 56Kb modem people, perhaps we can
construct a numpy-lite, but it shouldn't be the standard
distribution. I don't mind the financial functions going into numpy.
I think it's a good idea since a lot of people may find that very
handy to be part of the core distribution, probably many more than
worry about more exotic packages, and likely many more than care
about fft, random and linear algebra.
4) The api interface is perhaps a good idea, but as Travis mentions
can be deferred. But I don't think I would need it. (see 1)
More information about the Numpy-discussion