DEP: Deprecate inexact matches for mode, searchside

[anirudh2290]

Depends on #16009

Please see the discussion here : #16007 (comment)

[eric-wieser]

Think you had a typo in the PR title, corrected it.

[eric-wieser]

Needs a rebase to clear out the first two commits

[anirudh2290]

1. I deprecated byteorder inexact and case insensitive matches. For byteorder, I see that the test used 'big', 'little' etc. I changed it to 'B', 'L' etc. and deprecated the other non symbolic usages ('b' or 'big' or 'biggish').
2. Removed the doc in certain places which have deprecated usage and added a deprecation note.
3. Modified the tests and code which have deprecated usage.

[eric-wieser]

big and little are consistent with sys.byteorder, so I don't think we want to deprecate them.

[anirudh2290]

I did this since some of the numpy documentation uses 'B' 'L' etc. for byte order : https://numpy.org/doc/stable/reference/generated/numpy.ndarray.newbyteorder.html?highlight=numpy%20ndarray%20newbyteorder#numpy.ndarray.newbyteorder and I felt deprecating such usage may have more impact on our existing users than in other deprecations. What do you suggest here ? Should we skip byteorder deprecation or just deprecate non exact matches of 'big', 'little' etc.

[seberg]

Ah, I had missed the sortkind proposal. I am not sure I like it. First of all, we currently have quicksort in the documentation so I think that is good enough reason that we should keep it supported.
The question is whether we want to change the documentation to prefer the shorthand quick, but it seems to me that "quick" may be misleading, since it may be the slower sorter while "quicksort" is the name of the algorithm (for those who know it). (if it was algoirthm= and not kind= I would maybe think differently)

In other words, my first gut feeling would be to leave it as the current docs do it. I am happy to keep supporting quick and/or q as well though.

[anirudh2290]

The question is whether we want to change the documentation to prefer the shorthand quick, but it seems to me that "quick" may be misleading, since it may be the slower sorter while "quicksort" is the name of the algorithm (for those who know it). (if it was algoirthm= and not kind= I would maybe think differently)

I agree 'quick' vs 'quicksort' can cause some confusion. I think I will revert my changes for sortkind and byteorder for now and just keep the deprecation limited to mode, order and searchside for now.

[seberg]

@anirudh2290 now that 1.19 is branched may be a good time to finish this. Just scrolled through, seems at least the "quick" documentation changes are still there.

[anirudh2290]

Just scrolled through, seems at least the "quick" documentation changes are still there.

Thanks @seberg for pointing this out, for some reason I thought this was done. will check again .

[seberg]

Thanks Anirudh, looks very nice. The only thing that makes me hesitate a bit is that I just checked scipy, and there are a few files that seem to use order='c' (it seems mainly two files, one file has order="f"), which might indicate that lower cases are used occasionally.

We may get away with it though, but could maybe fixup scipy before in either case? But if anyone has doubts, please say so, because otherwise one of these days I may decide to merge it :).

[mattip]

The mailing list discussion did not generate much feedback, but I am concerned that this may bite downstream packages and users. Are we really sure that pandas/astropy/Dask have no problem with this?

[seberg]

Well, I checked those large packages for the ones that would be likely order="f" (with lower case) and side="l" as a shorthand, and only found 3 files in SciPy.

I would be happy with keeping the lower case, if we expect those 3 usage/files in SciPy indicate that it is common enough that we do not want to create churn. That I feel would be the main point, unnecessary churn opposed to the advantage of unified style.

[mattip]

I would be happy with keeping the lower case, if we expect those 3 usage/files in SciPy indicate that it is common enough that we do not want to create churn.

That would be good

[anirudh2290]

Thanks @seberg and @mattip . I have addressed the review comments and removed order from deprecation to avoid churn. Thanks for checking the downstream projects @seberg ! I also ran the tests for pandas, dask, scipy and didnt find anything except the usage that you mentioned.

[seberg]

Thanks Anirudh! Let me put this in.