[Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)

[Perry Greenfield]

On Apr 7, 2008, at 2:29 PM, Robert Kern wrote:
> On Mon, Apr 7, 2008 at 11:19 AM, Bruce Southey <bsouthey at gmail.com>  
> wrote:
>>  Hi,
>>  I think that splitting the NumPy namespace should not happen  
>> within a
>>  major release series because it would cause too many breakages.   
>> Rather
>>  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  
>> same
>>  time, Python 3K would be  fully supported because it will break  
>> lots of
>>  code.
>
> 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.
>
Amen.

>>  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.
>
Me too.

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)

Perry