BUG: raise TypeError for in-place string multiply via arithmetic operator #29056
Conversation
| @@ -16,7 +16,7 @@ | |||
| MAR_M_dt64: MaskedArray[np.datetime64] = np.ma.MaskedArray([np.datetime64(1, "D")]) | |||
| MAR_S: MaskedArray[np.bytes_] = np.ma.MaskedArray([b'foo'], dtype=np.bytes_) | |||
| MAR_U: MaskedArray[np.str_] = np.ma.MaskedArray(['foo'], dtype=np.str_) | |||
| MAR_T = cast(np.ma.MaskedArray[Any, np.dtypes.StringDType], np.ma.MaskedArray(["a"], "T")) | |||
| MAR_T = cast(np.ma.MaskedArray[Any, np.dtypes.StringDType], np.ma.MaskedArray(["a"], dtype="T")) | |||
There was a problem hiding this comment.
I happened to notice that this was passing "T" as the mask, so the resulting array had dtype='U1'. Perhaps not great that MaskedArray doesn't object if you pass mask=some_string!
|
Hmmm, sorry hadn't quite thought that through. This works to prevent in-place ops, it will not fix |
Yeah this is probably the way to go. We can get the value of the right hand side, compare it with the dtype's width, and use that bound to prevent any of the loops from overflowing the buffer. That way I can also avoid messing with the types or breaking backward compatibility, even if in-place multiplying a string is a weird thing to do... I'm going to re-issue this with a different approach. |
Fixes #29011.
I could add bounds checking to the loops themselves too, if people think it's worth adding that defensively.