The problem with using the promoter is I'm not handed dtype instances, only the dtypemetas. That means in resolve_descriptors where we originally had a python string we get handed the default stringdtype instance.

Maybe this is a use case for resolve_descriptors_with_scalars?

That means in resolve_descriptors where we originally had a python string we get handed the default stringdtype instance.

If you just add a promoter you should be getting a new StringDType not an old one, unless you register the loop with the old one, since the promoter will force using the new-style StringDType on all arguments.

If you just add a promoter you should be getting a new StringDType not an old one, unless you register the loop with the old one, since the promoter will force using the new-style StringDType on all arguments.

Sorry if I was unclear, I was talking about distinct StringDType instances where equality comparisons return false, like in the test I added in this PR.

Right now on the main branch this is an error:

In [1]: import numpy as np

In [2]: arr = np.array(["hello", "world"], dtype=np.dtypes.StringDType(na_object=None))

In [3]: np.strings.find(arr, 'wor')
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[3], line 1
----> 1 np.strings.find(arr, 'wor')

File ~/Documents/numpy/build-install/usr/lib/python3.11/site-packages/numpy/_core/strings.py:238, in find(a, sub, start, end)
    206 """
    207 For each element, return the lowest index in the string where
    208 substring ``sub`` is found, such that ``sub`` is contained in the
   (...)
    235
    236 """
    237 end = end if end is not None else MAX
--> 238 return _find_ufunc(a, sub, start, end)

TypeError: Can only do binary operations with equal StringDType instances.

This PR avoids the error by casting the needle string to arr's dtype.

It's not clear to me how to fix this using a promoter only, because the error path that's generating the TypeError above is in resolve_descriptors, after the promoter has already run.

I suppose you don't have a "cannot be a NULL object" (since that can be used with another one in a binary operation just fine)? But in that case yes, you need to either:

• Register the loop with the legate string (even if it ends up using your string!)
• Use the other resolver function, since the cast is not done for you there.

Although, I think it would make sense to see if the str->string cast cannot return a StringDType instance which works here.

Although, I think it would make sense to see if the str->string cast cannot return a StringDType instance which works here

Yes, I wonder if one cannot have a (possibly internal only) StringDType that is equal to all others and takes on their object_NA.

OK, fair enough. I'm going to come back to this with a different approach.