Use DeprecationWarning instead of FutureWarning for is_.._dtype deprecations

[jorisvandenbossche]

xref #54970

Those kind of helpers functions are, I think, for a large part used by other libraries, and to a lesser extent by direct user code. For that kind of deprecations, we first start with a DeprecationWarning, so it's not visible for the end-user (like users of seaborn got a flood of warnings before their latest release).

Of course, changing it now might also give some churn in case some other projects already added some code to suppress them, but I think it's still useful to do now (many people have not yet upgraded to 2.1).

[rhshadrach]

Of course, changing it now might also give some churn in case some other projects already added some code to suppress them, but I think it's still useful to do now (many people have not yet upgraded to 2.1).

People may have not upgraded, but downstream packages? If a package is dependent on pandas I would imagine it is likely to become "2.1-compliant" faster than end users. Though hopefully packages are not handling warnings by suppressing them 😆 If they are though, and they are suppressing the FutureWarning, they will have to change it to a DeprecationWarning, then back to FutureWarning (assuming they haven't addressed it).

I'm on the fence here.

[jorisvandenbossche]

People may have not upgraded, but downstream packages? If a package is dependent on pandas I would imagine it is likely to become "2.1-compliant" faster than end users.

Taking the example of seaborn, which is a well maintained package, that only had a release fixing this a few weeks after the pandas release. And I expect there to be many packages that are slower than the seaborn maintainer (note that it is not enough to fix this but also to release).

[jorisvandenbossche]

And indeed, if they addressed the warning, they either fixed it (and this PR won't change anything for them), or either they suppressed it temporarily, and then they will see the warning again (requiring them to suppress it temporarily again, or prompt them to actually fix it)

[rhshadrach]

I'm good with changing to a DeprecationWarning, but would like to get thoughts from those who originally deprecated. cc @jbrockmendel @phofl @mroeschke

[jbrockmendel]

fine by me

[rhshadrach]

lgtm

[rhshadrach]

This failure looks related. https://github.com/pandas-dev/pandas/actions/runs/6653673736/job/18080148037?pr=55703#step:8:107

[mroeschke]

LGTM. Merge when ready @rhshadrach

[rhshadrach]

Thanks @jorisvandenbossche

[lumberbot-app]

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout 2.1.x
git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -x -m1 d36fb98ddba74631812f113050c0a6f945868051

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #55703: Use DeprecationWarning instead of FutureWarning for is_.._dtype deprecations'

4. Push to a named branch:

git push YOURFORK 2.1.x:auto-backport-of-pr-55703-on-2.1.x

5. Create a PR against branch 2.1.x, I would have named this PR:

"Backport PR #55703 on branch 2.1.x (Use DeprecationWarning instead of FutureWarning for is_.._dtype deprecations)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.