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

Fernando Perez Fernando.Perez at colorado.edu
Thu Jan 5 00:47:13 CST 2006


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




More information about the Scipy-dev mailing list