✔️ Linting Passed

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

_{Generated for commit: 6547842. Link to the linter CI: here}

Ping @thomasjpfan and @Micky774 for review.

One inconsistency I see compared to the similar functionality that was added in #21901 for fetch_openml:

• delay is an int in this PR
• delay is a float in ENH Add a retry mechanism in fetch_openml #21901

I think it would make sense to have delay be a float in this PR.

Also not sure whether that was discussed in related issues/PRs (I looked quickly but could not find any discussion about this), but were there some thoughts about reusing the same code both in this PR and for fetch_openml? I would be completely fine if this was done in a further PR.

I think it would make sense to have delay be a float in this PR.

I'll update the delay parameter to float.

Also not sure whether that was discussed in related issues/PRs (I looked quickly but could not find any discussion about this), but were there some thoughts about reusing the same code both in this PR and for fetch_openml? I would be completely fine if this was done in a further PR.

I do not think there was any discussion about reusing the same code. After finishing this PR I can open another one with the decoupled retry mechanism into a separate function.

cc @lesteve

Also not sure whether that was discussed in related issues/PRs (I looked quickly but could not find any discussion about this), but were there some thoughts about reusing the same code both in this PR and for fetch_openml? I would be completely fine if this was done in a further PR.

I do not think there was any discussion about reusing the same code. After finishing this PR I can open another one with the decoupled retry mechanism into a separate function.

I jumped the here. What did you mean when you say "reusing the same code both in this PR and for fetch_openml."? Did you mean reusing the _fetch_remote function, where retry and delay are implemented, in fetch_openml?

Also, please look at the fetch_20newsgroups_vectorized because I managed to miss it the first time!

cc @lesteve

Also pointing out another inconsistency:

In this PR the functions use the following constraints on delay parameter: (Real, 1.0, None, closed="left"), while the fetch_openml function uses (Real, 0.0, None, closed="right"). Should I switch to the latter?

It makes sense to use (Real, 0.0, None, closed="right") I think, since the delay can be between 0 and 1.

What did you mean when you say "reusing the same code both in this PR and for fetch_openml."? Did you mean reusing the _fetch_remote function, where retry and delay are implemented, in fetch_openml?

This was a rather vague idea since I did not look carefully at the code, but it feels like maybe the retry code is very similar so there could be a function that is reused between the two implementations.

It makes sense to use (Real, 0.0, None, closed="right") I think, since the delay can be between 0 and 1.

Do not see why a delay time between retries should be limited to a maximum of 1 second, or confined to a range between 0 and 1 seconds.

Actually can you use Interval(Real, 0.0, None, closed="neither")?

Sorry I was not explicit enough in my previous message Interval(Real, 0.0, None, closed="neither") means between 0 and +infinity with both 0 and infinity excluded.

The current code [Interval(Real, 1.0, None, closed="left")] means between 1 and +infinity, 1 included. We do want to accept a delay between 0 and +infinity.

Actually can you use Interval(Real, 0.0, None, closed="neither")?

Yes, I believe this is the most sensible solution.

LGTM, thanks!

I fixed a conflict in the changelog and set auto-merge: this will automatically be merged when CI is green.

So the failures are in main too, see #27700 (comment)

Apparently we broke something. Since we skip the test for the fetcher we did not catch it.
I'll make a PR to fix it.