DEPR: downcasting in NDFrame.where, mask, clip

[jbrockmendel]

• closes #xxxx (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

Related to #40988.

This doesn't have a good "do X to avoid the warning/get the future behavior". Could be a use case for the "future" option from #53025

Alternative to #53108

[jbrockmendel]

@rhshadrach thoughts here?

[rhshadrach]

+1 on the future behavior.

Agree this is a good candidate for a future.* option. The other option would be to add an argument to Series.where and DataFrame.where for the change in behavior. The benefit of the argument would be that it doesn't rely on global state and is more explicit. The downside is that users can't just adopt the future behavior everywhere in a single line of code. No clear winner in my mind - I'm good either way.

Edit: I forgot this was impacting multiple methods. That makes me favor the option rather than argument quite a bit more.

[jbrockmendel]

@mroeschke @MarcoGorelli on board for implementing the future option here?

[MarcoGorelli]

yeah sounds good to me!

[MarcoGorelli]

implementing the future option here?

is that something you want to do as part of this PR?

[jbrockmendel]

is that something you want to do as part of this PR?

I was planning to, yes. But if people were OK on doing this deprecation without a "do X instead" id also be happy do move forward as is

[jbrockmendel]

@mroeschke thoughts here? im making a push to deprecate all our remaining silent downcasting and this is the hard one i think. im OK either to do this without a "do X instead" or to implement a "future" option.

[mroeschke]

I think being more conservative with a future option would be better here since there seem to be no current way to work around this warning.

[jbrockmendel]

I think being more conservative with a future option would be better here since there seem to be no current way to work around this warning.

updated with future option. could plausibly re-use that in #54710, #54261

[mroeschke]

Thanks @jbrockmendel