10000 MNT Remove utils.fixes after Python 3.10 bump by lesteve · Pull Request #31022 · scikit-learn/scikit-learn · GitHub
[go: up one dir, main page]

Skip to content

MNT Remove utils.fixes after Python 3.10 bump #31022

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

Merged

Conversation

lesteve
Copy link
Member
@lesteve lesteve commented Mar 19, 2025

Follow-up of #30895.

Copy link
github-actions bot commented Mar 19, 2025

✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

Generated for commit: d3200de. Link to the linter CI: here

Copy link
Member
@thomasjpfan thomasjpfan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -19,9 +19,9 @@

import numpy as np
import scipy
from scipy.optimize._linesearch import line_search_wolfe1, line_search_wolfe2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's unfortunate that we are using a private function in SciPy.

Copy link
Member
@jeremiedbb jeremiedbb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's this def that has not been cleaned up at the bottom of fixes:

# TODO: Remove when python>=3.10 is the minimum supported version
def _dataclass_args():

# Use filter="data" to prevent the most dangerous security issues.
# For more details, see
# https://docs.python.org/3.9/library/tarfile.html#tarfile.TarFile.extractall
fp.extractall(path=lfw_home, filter="data")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we don't intend to do it in the CI, let's put a pragma no cover

Copy link
Member
@jeremiedbb jeremiedbb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, nice clean-up !

@jeremiedbb
Copy link
Member

oh, looks like there's an issue with the dataclasses

@lesteve
Copy link
Member Author
lesteve commented Mar 25, 2025

oh, looks like there's an issue with the dataclasses

Looks like mypy but only in the CircleCI linting not the Azure one. Let me update my branch, this may help fixing this.

@lesteve
Copy link
Member Author
lesteve commented Mar 25, 2025

CI is green now, except codecov because some datasets fetching code is not covered by our tests. I think that's fine, codecov has never been a blocker in the past.

@jeremiedbb
Copy link
Member

CI is green now, except codecov because some datasets fetching code is not covered by our tests. I think that's fine, codecov has never been a blocker in the past.

see #31022 (comment), I think it's worth adding pragmas where we know we don't want to test it in CI such that it slowly reduces the frequency of coverage failures coming from moving an uncovered line around.

@lesteve
Copy link
Member Author
lesteve commented Mar 25, 2025

see #31022 (comment), I think it's worth adding pragmas where we know we don't want to test it in CI such that it slowly reduces the frequency of coverage failures coming from moving an uncovered line around.

Yeah I saw your comment but I am a bit 🤷 about it.

Personally, I am fine with codecov being red, having a quick look at the codecov report, deciding that it kind of makes sense that it is not covered by the CI and maybe run the function locally to make sure that it works if I feel the need to be 100% sure.

The alternative is adding a pragma nocover to make codecov green and maybe missing the fact that you changed a line which is not covered by the tests.

Personally I am slightly leaning towards not bothering about adding a pragma nocover but sure I will do it if there is consensus on the pragma nocover option 😉.

@ogrisel
Copy link
Member
ogrisel commented Mar 25, 2025

I think adding # pragma: no cover markers where appropriate has several advantages:

  • it avoids having the PR author write comments such as MNT Remove utils.fixes after Python 3.10 bump #31022 (comment) to explain to maintainers that they can productively do a final pass of review
  • it communicates an explicit message when we expect a given line of code to be counter-productive (e.g. too costly/flaky as is the case) to cover with tests. This can be helpful for people reading the code outside a given PR context.

But let's not delay the merge of this PR for this.

@ogrisel ogrisel merged commit 5b1f9ec into scikit-learn:main Mar 25, 2025
32 of 33 checks passed
@lesteve lesteve deleted the remove-fixes-after-python-3.10-bump branch March 26, 2025 07:38
lucyleeow pushed a commit to lucyleeow/scikit-learn that referenced this pull request Apr 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0