[SciPy-dev] Now new svn of numpy is ready

[Pearu Peterson]

I agree with Fernando's analysis. If we keep numpy objects in scipy 
namespace then  users can do

   from scipy import *

to get fast fft, etc and so keeping numpy scipy-clean.

The current problems are due to the fact that scipy is being imported
while numpy import is not finished. To resolve this, overwriting fft and 
other routines should be carried out at the end of numpy/__init__.py and 
this can be accomplished with calling scipy_enable style functions at the 
end of __init__.py.

Pearu


On Wed, 4 Jan 2006, Fernando Perez wrote:

> Travis Oliphant wrote:
>
>> But these need to be there.  We need some way to update the functions in
>> numpy if scipy is installed (so that you  can always call the numpy
>> functions but get the scipy functions if they are there)...
>
> Mmh, I'm not sure I agree with this approach.  I think this may lead to
> surprising behavior, hard to find bugs, etc.  I really don't think that the
> presence of scipy should change the behavior of numpy's internals, esp. when
> we're advertising the dependency chain to be
>
>   	numpy < scipy
>
> Finding out that in reality, there's a hidden
>
>        |-> numpy   scipy--|
>        |                  |
>        |------------------|
>
> cycle kind of threw me for a loop :)
>
> I would argue that users should know whether they want to call scipy's
> libraries or numpy's, and be clearly aware of the differences.
>
> For example, publishing a benchmark based on code that uses numpy on one
> system may be misleading: you write
>
> from numpy import foo
> foo()
>
> and publish that it takes 0.1s to run.  Then somebody downloads your code,
> they run it and get significantly different results.  Still, you swear that's
> what you get.  It turns out the other user didn't have scipy installed, only
> numpy, but you had scipy on your system, and the difference in performance was
> being caused by this hidden overwriting.
>
> IMHO, we should follow here the whole 'explicit is better than implicit'
> thingie.  If people want to get the benefits of scipy, they should say so
> explicitly and use scipy.
>
> I can also see the flip side of the argument: installing scipy can give you a
> 'magical' performance boost in your numpy code, without having to rewrite
> anything.  But the more I write larger codes, the more I end up disliking
> hidden side-effects: in the long run, they always seem to cause more headaches
> than their apparent initial benefit.
>
> Perhaps a compromise solution would be to have something like
>
> numpy.scipy_enable()
>
> which would trigger the overwriting.  At least this would force the users to
> make an explicit call, so they are aware of what's going on.  This would
> obviously be a no-op if scipy isn't present, nicely wrapping the 'import
> scipy' in a try/except (as it is today).
>
> Well, it's ultimately your call, but I wanted to at least express my view.
>
> Cheers,
>
> f
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>