The alternative would be to fall back to PyUnicode_FindChar or PyUnicode_Contains on the understanding that this would be a rarely used slow path. Both of these would require Python error handling (in a function that isn't supposed to return exceptions)

The right fallback is probably what already follows just below for the pre-3.9 case, except that we'd have to use wchar_t instead of Py_UNICODE.

The right fallback is probably what already follows just below for the pre-3.9 case, except that we'd have to use wchar_t instead of Py_UNICODE.

That still requires PyUnicode_AS_UNICODE - there doesn't seem to be a way to access the data as wchar_t instead of Py_UNICODE.

That suggests to me that the right thing to do is revert 3363638 but wrap the whole thing in

#pragma GCC diagnostic push  // works for clang too
#prgama GCC diagnostic ignored "-Wdeprecated"

// code...

#pragma GCC diagnostic pop

(just to make the warnings go away.) Possibly with something similar for MSVC too.

Actually, WCHAR_KIND is already scheduled for removal in Py3.12 and PyUnicode_IS_READY() as well. I'll see if I can come up with something reasonable here.

See #4135 for an attempt to make this more future proof.

Superseded by #4135.