I'm a bit undecided if this is worth the deprecation cycle. I think it comes down to "do we want to switch from affinity everywhere". If yes, then I think it's worth going through deprecation.

It's definitely something that should happen in series, if at all, otherwise having only some mentions move to metric while some stay affinity would be very painful.

I think the questionable case is AffinityPropagation. Should affinity in AffinityPropagation by renamed to metric?

I think that should stay affinity. The docstring specifies that affinity="precomputed" does indeed expect a similarity matrix, and that affinity="euclidean" uses the negative squared Euclidean distances, which is a similarity.

I just sync with main since we introduced the parameter validation since this PR was open.

Could you modify the following example as well to avoid raising the warning:

• examples/cluster/plot_agglomerative_clustering_metrics.py
• examples/cluster/plot_cluster_comparison.py (I see that we might have the same inconsistency in SpectralClustering).

Could you modify the following example as well to avoid raising the warning:

• examples/cluster/plot_agglomerative_clustering_metrics.py
• examples/cluster/plot_cluster_comparison.py (I see that we might have the same inconsistency in SpectralClustering).

Fixed, good catch.

I think that SpectralClustering is fine since it genuinely builds an affinity/similarity matrix. In particular affinity="precomputed" demands an affinity/similarity matrix.

LGTM THanks @Micky774

Hi! Can we change just change the keyword from affinity to metric in scikit-learn 1.2 without a change in behaviour? Any exceptions or caveats?

Hi! Can we change just change the keyword from affinity to metric in scikit-learn 1.2 without a change in behaviour? Any exceptions or caveats?

Yes, you should be able to replace affinity-->metric with no change in behavior!