CI Run free-threaded test suite with pytest-run-parallel #32023
Conversation
5e0ee8f to
47b7d33
Compare
… around _check_stop_words_consistency and avoid a weird side effect
…314t package is on conda-forge
| @@ -1329,18 +1329,19 @@ def test_vectorizer_stop_words_inconsistent(): | |||
| vec.fit_transform(["hello world"]) | |||
| # reset stop word validation | |||
| del vec._stop_words_id | |||
| assert _check_stop_words_consistency(vec) is False | |||
| with pytest.warns(UserWarning, match=message): | |||
There was a problem hiding this comment.
This is the actual fix, see previous discussion in #32023 (comment).
My guess right now is that the first call _check_stop_words_consistency was raising a warning and that the next pytest.warns was sometimes failing because of the default warnings once strategy plus some unfavourable thread ordering. By putting this inside pytest.warns we avoid the side-effect and the second warning is always issued.
| warnings.simplefilter("error", UserWarning) | ||
| vec.fit_transform(["hello world"]) | ||
| assert _check_stop_words_consistency(vec) is None | ||
| # Only one warning per stop list |
There was a problem hiding this comment.
This was an oversight. This puts this block inside the for loop. Previously, this block was not inside the for loop so only the last element of the loop was tested ...
| # if the parameter is deprecated, don't show it | ||
| continue | ||
| finally: | ||
| warnings.filters.pop(0) |
There was a problem hiding this comment.
I rewrote this test a bit to rely on warnings.catch_warnings to reset the warnings filters.
With Python 3.14 free-threading, warning.simplefilter does not modify warnings.filters any more inside a warnings.catch_warnings context, see https://docs.python.org/3.14/whatsnew/3.14.html#concurrent-safe-warnings-control.
…nto free-threaded-pytest-run-parallel
|
codecov being red is likely because there is no coverage in the free-threaded CI build. I guess we could look at this in a further PR but I don't think this is very high priority: |
|
Thanks @lesteve! |
Part of #30007
Edit: scipy free-threaded Python 3.14 package was added in conda-forge so the following 2 points are not a problem anymore:
conda-lock has a bug with rc Python versions, I generated the lock-file with a local work-aroundI opened Handle Python release candidates in PyPI solver conda/conda-lock#837 about thisconda-lock does not pick the right free-threaded pip wheel. This is an issue because there is not scipy conda package for free-threaded Python 3.14 yet. I manually tweaked the wheel URL in the lock-file. See free-threaded wheel not picked in pip dependencies conda/conda-lock#754 for the conda-lock bug.