[Numpy-discussion] import overhead of numpy.testing
Sun Aug 11 15:24:19 CDT 2013
On Aug 11, 2013 5:02 AM, "Ralf Gommers" <firstname.lastname@example.org> wrote:
> On Sun, Aug 11, 2013 at 3:35 AM, Benjamin Root <email@example.com> wrote:
>> Would there be some sort of way to detect that numpy.testing wasn't
explicitly imported and issue a deprecation warning? Say, move the code
into numpy._testing, import in into the namespace as testing, but then have
the testing.py file set a flag in _testing to indicate an explicit import
>> Eventually, even _testing would no longer get imported by default and
all will be well.
>> Of course, that might be too convoluted?
> I'm not sure how that would work (you didn't describe how to decide that
the import was explicit), but imho the impact would be too high.
The idea would be that within numpy (and we should fix SciPy as well), we
would always import numpy._testing as testing, and not import testing.py
ourselves. Then, there would be a flag in _testing.py that would be set to
emit, by default, warnings about using np.testing without an explicit
import, and stating which version all code will have to be switched by
testing.py would do a from _testing import *, but also set the flag in
_testing to not emit warnings, because only a non-numpy (and SciPy) module
would have imported it.
It isn't foolproof. If a project has multiple dependencies that use
np.testing, and only one of them explicitly imports np.testing, then the
warning becomes hidden for the non-compliant parts. However, if we make
sure that the core SciPy projects use np._testing, it would go a long way
to get the word out.
Again, I am just throwing it out there as an idea. The speedups we are
getting right now so far are nice, so it is entirely possible that this
kludge is just not worth the last remaining bits of extra time.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion