Consider reverting the renaming of compiled c test modules (part of the pytest move)? #10845
Comments
By affect, @lesteve means that it will raise an error if one imports anything from |
|
I guess
```
# numpy/core/umath_tests.py
from __future__ import division, absolute_import, print_function
import warnings
warnings.warn(("numpy.core.umath_tests is an internal Numpy "
"module and should not be imported. It will "
"be removed in a future Numpy release."),
category=DeprecationWarning)
from ._umath_tests import *
```
|
|
I'll put a shim in for this as suggested by @pv, also change the warnings in the |
|
This seems fine as far as scikit-learn is concerned, thanks a lot for tackling this! |
|
Hmm, I've actually been using those routines as the only functioning examples of |
Yes. I note that many of the linalg functions are using gufuncs, what exactly do you need for test cases? |
|
Functions that are simple and can be easily used to check |
Just so. And if it was obvious we wouldn't be having this problem :) Where are you using them for test cases? NumPy using them is not a problem. |
|
I'm not using them on anything public - my comment was mainly to support @lesteve's note that there may well be more code that expects to find these functions, and one should wonder whether the arguably minor costs are worth what seems a very minor benefit of the name change. (But since it is all about very minor things, and it doesn't really affect me, just decide what you think best!) |
|
It's not a minor cost. If we change or rearrange numpy internals and people complain, that is a major cost. And we will be doing a lot of rearrangement going forward. If you have tests for |
|
Yes, there are tests for Note that I am probably missing the big picture here about the larger re-arrangements that are planned. |
|
Ah, OK. Those tests were already adjusted. We will be merging the umath and multiarray modules. In general, I think we are heading to fewer modules in |
|
Yes, of course! That overall plan definitely sounds good! |
|
See #10850. |
The following modules have been moved or renamed and should not be imported. This adds shim modules for the old names that issue a DeprecationWarning on import. * numpy/core/umath_tests.py * numpy/testing/decorators.py * numpy/testing/noseclasses.py * numpy/testing/nosetester.py * numpy/testing/utils.py Closes numpy#10845.
|
I want to note that I'm working with a numpy-based ray-tracing code where row-wise dot products are by far the most common operation that I do and I've been starting to use Should I open a feature request to make |
|
I think we will be adding several new ufuncs for these types of stacked arrays/vectors in the future, so I would prefer to wait on that. |
|
@charris : Thanks for the fast answer. Looking forward to seeing them! |
|
@charris Is there a specific reason why you gave the warnings a stacklevel of 2? I don't see it turning up in the discussion, and since it isn't called in a wrapper the need isn't obvious to me. I noticed it because the stackframe-nesting leads to weird side-effects like pytest not being able to suppress them because it only checks the first layer. Edit: Or should I open an issue for this? |
|
We try to make the error messages come from the point of call. How are you suppressing the warnings in pytest. You might open an issue for discussion. |
|
For deprecation- and user-warnings, pytest does it on its own by default. I'll open an issue then. |
The renaming of compiled c test modules in #10790 broke the scikit-learn tests because we were using
numpy.core.umath_tests.inner1d. There was no good reason to useinner1dand we now used standard numpy constructs in scikit-learn master. The problem is that it will affect the latest scikit-learn (0.19.1) as soon as numpy 1.15 is released. Given the current rate of release, it is rather likely that numpy 1.15 will be released before the next scikit-learn release (0.20).It feels like other projects could be using some of the renamed modules, so maybe the safest approach would be to keep the old modules around for a deprecation cycle with a DeprecationWarning saying that this modules are for numpy internal use only. Would you be willing to consider this option?
I first commented in #10790 (comment) but @charris suggested I opened a new issue, so here it is!
The text was updated successfully, but these errors were encountered: