Since StringDType has char code "T", you could use T_co instead of S_co for it.
That way, the one for bytes doesn't have to be renamed to B_co, additionally avoiding it being confused with uint8 (which has char code B).
It'll help reduce the amount of changed as as well :)

I also am not able to make expression like np.split(AR_S, ' ') type check properly

Maybe I'm missing something, but the second argument of numpy.split should be an int or an array-like of ints according to the docs 🤔

And numpy.strings.split doesn't exist (at least not in the main branch)?

I also am not able to make expression like np.split(AR_S, ' ') type check properly, since from the type-checker's perspective ' ' is convertible to a unicode array, but in reality in the way we set up the promoters for StringDType, this does return a StringDType array. I had to cheat for functions like that where normally people pass scalars but it's typed to be able to accept an array by passing in an AR_S in the reveal tests where the unicode tests pass in a scalar.

Ah after applying my mental autocorrect function, I realized that you're talking about numpy.string.strip 👍🏻 . I can kinda relate to this, as I once made the mistake to ask for a "stripper" instead of a "splitter" in a hardware store 😅.

Anyway, I don't think that the issue here has to do with the fact that str_ array-likes also accept raw strs, because there's no overlap between U_co and S_co (the T / StringDType one).

@overload
def strip(a: S_co, chars: None | S_co = ...) -> np.ndarray[_Shape, np.dtypes.StringDType]: ...

The chars parameter is of None | S_co, which resolves to _SupportsArray[StringDType] | None.

When call numpy.string.split(AR_S, " "), then a is inferred as an ndarray of StringDType, which matches the a: S_co parameter of this only overload.
So the typechecker won't look at any other overloads at this point (so your pattern matching mindset is indeed the right way to look at it).
Now the 2nd argument " " is inferred as chars: str. But str can't be assigned to None, and also not to _SupportsArray[StringDType] (because str doesn't implement __array__).
At this point, there are no overloads left, and we're left stranded in the "land of undefined behavior".

So to make a short story long: the chars in the StringDType overload should probably also accept a str.

Argh, so it looks like the mypy tests are failing here and they didn't fail locally for me because this PR branch is based on main before #27419.

After #27419, this is no longer an error and I have no idea why:

FAILED numpy/typing/tests/test_typing.py::test_fail[strings] - AssertionError: Error mismatch at line 7
E           AssertionError: Error mismatch at line 7
E
E           Expression: np.char.equal(AR_U, AR_S)
E           Expected error: incompatible type
E           Observed error: ''

(Note that this is after fixing a logic error in test_fail which flipped the expected and observed error printouts)

I think I responded to everything with the latest push.

I'll finish this off if I can get some help with the test failures and the question I just posted above.

I'll finish this off if I can get some help with the test failures and the question I just posted above.

The test failure seems to be a result of an import issue with StringDType in numpy._typing._array_like:

So when mypy doesn't know what something is, it just treats is as if its Any, which explains why np.char.equal(AR_U, AR_S) doesn't fail.

OK, only remaining failure I see is unrelated.

Thanks so much for your help with this @jorenham!

Needs rebase, some of the reveal tests have been removed.

I'll try to get this updated soon, I just finished a short vacation today and hopefully I'll have some time to work on this later this week.

I think this is good to merge now.

I think this is good to merge now.

I agree 👌🏻

Thanks @ngoldbaum!