-
-
Notifications
You must be signed in to change notification settings - Fork 26k
MAINT fix deprecation raised in scipy-dev build #25175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MAINT fix deprecation raised in scipy-dev build #25175
Conversation
sklearn/externals/_lobpcg.py
Outdated
@@ -22,11 +22,12 @@ | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will revert those changes where black
decided that I should not only change a single line ;)
sklearn/externals/_lobpcg.py
Outdated
from scipy.sparse.linalg import aslinearoperator | ||
from numpy import block as bmat | ||
|
||
from ..utils.fixes import _eigh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently this is introducing a circular dependency in the doc builds...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, for the oldest version of SciPy, we are doing circular imports. Let me try to solve this one (I will revert black
as well).
sklearn/externals/_lobpcg.py
Outdated
@@ -19,7 +19,7 @@ | |||
.. [3] A. V. Knyazev's C and MATLAB implementations: | |||
https://github.com/lobpcg/blopex | |||
""" | |||
|
|||
import inspect |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to apply the following sync before making this change here:
The latest failure feels like a change in |
#25176 confirm that the issue is linked to the version of SciPy. |
Co-authored-by: Olivier Grisel <[email protected]>
sklearn/manifold/_locally_linear.py
Outdated
@@ -20,6 +20,7 @@ | |||
from ..utils import check_random_state, check_array | |||
from ..utils._arpack import _init_arpack_v0 | |||
from ..utils._param_validation import Interval, StrOptions | |||
from ..utils.fixes import eigh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be a private method? Historically, we have removed public functions from utils.fixes
without deprecation, which I always found inconsistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The advantage of having eigh
public is that the body of the code does not change in the future. What would make sense is to have fixes
private itself (i.e. _fixes
).
I don't know what is best here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The advantage of having eigh public is that the body of the code does not change in the future.
I don't understand this. Why would renaming it _eigh
be a problem?
+1 for deprecating sklearn.utils.fixes
in favor of sklearn.utils._fixes
in a follow-up PR anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @ogrisel:
- let's use
_eigh
for this PR - let's make
utils.fixes
private, I tried to find some past discussions about why it was not made private but I did not find anything in ~15 minutes. Maybe one reason I can think of is that we sometimes useutils.fixes
in examples and that it would be a bit weird to use private stuff in examples. Personally I can live with usingutils._fixes
in examples when the alternative makes the example code a lot more complicated. Right now we have 4 examples usingutils.fixes
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just pushed a commit doing that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @lesteve for the push. Since we are few utils.fixes
, it could be the right time to make it private and deprecate it (of course in another PR).
The codecov patch error is because some of the lines in the diff are not covered by tests, you can see them in the "Files tab" I check manually that indeed these lines are not covered by any tests. I don't think it should block this PR anyway. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I'm marking this for 1.2.1 so the deprecation warnings do not appear in |
Co-authored-by: Olivier Grisel <[email protected]> Co-authored-by: Loïc Estève <[email protected]>
Co-authored-by: Olivier Grisel <[email protected]> Co-authored-by: Loïc Estève <[email protected]>
Co-authored-by: Olivier Grisel <[email protected]> Co-authored-by: Loïc Estève <[email protected]>
Co-authored-by: Olivier Grisel <[email protected]> Co-authored-by: Loïc Estève <[email protected]>
Co-authored-by: Olivier Grisel <[email protected]> Co-authored-by: Loïc Estève <[email protected]>
closing #25164
Should be merged after:
importlib.resources
#25157