DEP: stats.kendalltau: remove deprecated parameter initial_lexsort

[mdhaber]

Reference issue

Closes gh-18578

What does this implement/fix?

This removes deprecated parameter initial_lexsort.

Additional information

Marked as draft pending resolution of #18578 (comment).

[rgommers]

To follow up on #18578 (comment), it looks to me like this keyword can't be removed at ll, because the deprecation was incomplete. kendalltau(x, y, None, 'omit', 'exact') never generated a warning, so the deprecation itself should be adjusted to do that now. And then in two releases from now, it can indeed be made keyword-only.

[j-bowhay]

To follow up on #18578 (comment), it looks to me like this keyword can't be removed at ll, because the deprecation was incomplete. kendalltau(x, y, None, 'omit', 'exact') never generated a warning, so the deprecation itself should be adjusted to do that now. And then in two releases from now, it can indeed be made keyword-only.

This is an interesting point that doesn't seem to have been brought up before. We have assumed this sort of thing was alright for a long time eg. #6948 without any complaints. Is this something we want to clean up? If so there are quite a lot of deprecations that are going to need bumping.

[rgommers]

We have assumed this sort of thing was alright for a long time eg. #6948 without any complaints.

In that example it was changed in the PR from False to None, presumably exactly to emit a warning if a user indeed used the previous default (False) explicitly. So the consideration isn't new I'd say. It was also a pretty niche keyword.

I think if it gets too non-idiomatic or weird, then we don't have to insist on a deprecation warning being 100% foolproof. But in this case it seems like a regular way to use positional arguments.

[j-bowhay]

@h-vetinari quite a lot of the issues are going to need adjusting based on this concern

[h-vetinari]

@h-vetinari quite a lot of the issues are going to need adjusting based on this concern

"this concern" being any changes to arguments that can also be used positionally? FWIW, we've been removing deprecated keyword(-also, not -only) arguments for the last few releases already (see log), but I guess it was only a handful each time and so the blast radius was limited.

[j-bowhay]

@h-vetinari quite a lot of the issues are going to need adjusting based on this concern

"this concern" being any changes to arguments that can also be used positionally? FWIW, we've been removing deprecated keyword(-also, not -only) arguments for the last few releases already (see log), but I guess it was only a handful each time and so the blast radius was limited.

Exactly. Unless you object, I am planning on going through all the current deprecations over the next couple of weeks to implement @rgommers suggestion where applicable. I imagine this is going to involve pushing the timeline back on a number of them. I am also planning on updating the dev docs section on deprecations to reflect the best practices we have accumulated over the last year or so