|
From: Fernando P. <Fer...@co...> - 2006-01-18 19:02:19
|
Travis Oliphant wrote: >>3) pkgload() exists to support the loading of subpackages. It does not reach >>into numpy.dft or numpy.linalg at all. It is not relevant to this issue. >> >>4) There are some places in numpy that use numpy.dual. >> >>I think we can address all of your concerns by changing #4. >> >> >> > > > This is an accurate assessment. However, I do not want to eliminate > number 4 as I've mentioned before. I think there is a place for having > functions that can be over-written with better versions. I agree that > it could be implemented better, however, with some kind of register > function instead of automatically looking in scipy... Mmh, I think I'm confused then: it seemed to me that pkgload() WAS overwriting numpy names, from the messages which the environment variable controls. Is that not true? Here's a recent thread: http://aspn.activestate.com/ASPN/Mail/Message/scipy-dev/2974044 where this was shown: In [3]: import scipy Overwriting fft=<function fft at 0x2000000001474668> from scipy.fftpack.basic (was <function fft at 0x2000000001394a28> from numpy.dft.fftpack) Overwriting ifft=<function ifft at 0x20000000014746e0> from scipy.fftpack.basic (was <function inverse_fft at 0x2000000001394aa0> from numpy.dft.fftpack) I understood this as 'scipy.fftpack.basic.fft overwrote numpy.dft.fftpack.fft'. Does this then not affect the numpy namespace at all? I also would like to propose that, rather than using an environment variable, pkgload() takes a 'verbose=' keyword (or 'quiet='). I think it's much cleaner to say pkgload(quiet=1) or pkgload(verbose=0) than relying on users configuring env. variables for something like this. Cheers, f |