DEPR (string): non-bool na for obj.str.contains

[jbrockmendel]

• closes BUG: .str.contains na validation #59561 (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.

No 2.3 whatsnew file yet. Not sure if the plan is to introduce one in #59513

[jorisvandenbossche]

I think startswith/endswith have the same issue? If so, can you add the same deprecation message there as well?

No 2.3 whatsnew file yet. Not sure if the plan is to introduce one in #59513

Yeah, we should start a 2.3 whatsnew file. We should add it to main, though (not in the backport PR), so things can be added to that file in PRs like this one.

[jbrockmendel]

I think startswith/endswith have the same issue? If so, can you add the same deprecation message there as well?

Sure, updated.

[jorisvandenbossche]

Actually, you could maybe move the warning to core/string/accessors.py, then you don't have to repeat it for the various implementations, and then also ArrowDtype(string) will get it (assuming we want to be consistent and also deprecate it for ArrowDtype, and not only for StringDtype?)

[jorisvandenbossche]

assuming we want to be consistent and also deprecate it for ArrowDtype, and not only for StringDtype?

Of course, that one already errors :)

[jbrockmendel]

then you don't have to repeat it for the various implementations

Because it already errors for the ArrowEA version (but with a pyarrow exception), patching it in the StringAccessor method would be bulky. I think the thing to do is wait until the deprecation is enforced, then do the validation in the StringAccessor method and get consistent exception/message.

[jorisvandenbossche]

Because it already errors for the ArrowEA version (but with a pyarrow exception), patching it in the StringAccessor method would be bulky. I think the thing to do is wait until the deprecation is enforced, then do the validation in the StringAccessor method and get consistent exception/message.

Sounds good!