Since this is fixing the bug reported in #23890, could you please add a FIX changelog entry for this estimator targeting 1.2? See doc/whats_new/v1.2rst.

Something like: NearestCentroid now only explicitly accepts Euclidean and Manhattan metrics and raise an informative error message at fit-time otherwise instead of failing with a low-level error message at predict-time.

Also, please remove the unecessary import reported by the linting runner on the continuous integration:

./sklearn/neighbors/_nearest_centroid.py:22:1: F401 'sklearn.metrics.pairwise._VALID_METRICS' imported but unused
from sklearn.metrics.pairwise import _VALID_METRICS
^

I just realized that the common test is also failing:

https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44573&view=logs&j=dde5042c-7464-5d47-9507-31bdd2ee0a3a&t=4bd2dad8-62b3-5bf9-08a5-a9880c530c94

but I don't understand why. Any idea @jeremiedbb or @glemaitre?

@glemaitre we actually need a changelog entry as explained in #23874 (comment).

@glemaitre we actually need a changelog entry as explained in #23874 (comment).

Oh yes I see. @2357juan Could you solve the linting problem and add an entry in the what's new

You'll also need to modify some tests in sklearn/neighbors/tests/teast_nearest_centroid.py to not use unsupported metrics, e.g.

test_iris
test_iris_shrinkage

and you can safely delete test_precomputed in the same file.

Since this is fixing the bug reported in #23890, could you please add a FIX changelog entry for this estimator targeting 1.2? See doc/whats_new/v1.2rst.

Something like: NearestCentroid now only explicitly accepts Euclidean and Manhattan metrics and raise an informative error message at fit-time otherwise instead of failing with a low-level error message at predict-time.

@ogrisel, the issue with the failure happening only at predict time only applies to wminkowski, seuclidean or mahalanobis. Many other metrics don't fail but are now rejected. As discussed in #23890, all metrics other than euclidean or manhattan raise a warning saying that averaging for these metrics is not supported, taking the mean instead. I don't think completely removing support for these metrics is a "bug fix", the behavior is intentional. If we really want to not support these metrics we should at least do a deprecation cycle imo.

I pushed a more conservative validation of the metric options with only discarding the failing at predict metrics. I think that if we really want to not support all metrics but euclidean and manhattan, we should make a proper deprecation in a separate PR.

LGTM then. We can open a subsequent PR as suggested by @jeremiedbb

LGTM then. We can open a subsequent PR as suggested by @jeremiedbb

I'm working on it (if that's OK with you @2357juan)