On Aug 11, 2013 5:02 AM, "Ralf Gommers" <ralf.gommers@gmail.com> wrote:
>
>
>
>
> On Sun, Aug 11, 2013 at 3:35 AM, Benjamin Root <ben.root@ou.edu> 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 has occurred?
>>
>> 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.
>
> Ralf
>

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 perhaps 2.0?).

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.