Seems fair.

But should we make it public ? I'd rather put it as an argument of _euclidean_distances_upcast and test this function. What do you think about that ?

But should we make it public ? I'd rather put it as an argument of _euclidean_distances_upcast and test this function. What do you think about that ?

At least for the bugfix we can test it on _euclidean_distances_upcast.

I would not be opposed to expose it in euclidean_distances as well, but I don't want to delay this PR if others do not agree.

Testability without an additional public parameter is one reason for working_memory being a global config

Testability without an additional public parameter is one reason for working_memory being a global config

Controlling the batch size with the working memory in the purpose of pairwise_distances_chunked. I'm not sure how it would interact if we control another batch size with the working memory in pairwise_distances.

Testability without an additional public parameter is one reason for working_memory being a global config

Alright but it makes the tests much less explicit. Maybe the code that compute the batch size from the working_memory parameter and the shape of the data could be externalized in a private function to be also tests in dedicated unit tests.

The test failure is unrelated: #13903.

Should we be aiming to release this pronto?

I guess so.

that is fairly explicit.

It's not explicit in the sense that we are testing the impact of the batch size. The rule that ties the working memory to the batch size is quite implicit and there is not easy way to write a test that guarantees that all the 3 cases that I mentioned above are covered: batch_size < n_samples (with n_samples % batch_size != 0 and n_samples % batch_size == 0) and batch_size >= n_samples.

It's not explicit in the sense that we are testing the impact of the batch size.

That indeed.

Merging, thanks @jeremiedbb !