[SciPy-dev] Now new svn of numpy is ready
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
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
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.
More information about the Scipy-dev