| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Hmmm, makes me wonder if we should consider something like result_type(*, dtypes=None, values=None). One huge problem with result_type after all is that it coerces to dtypes and kwargs could clean that up in theory. But yeah, making this helper deal with it makes more sense anyway probably, as it can more easily avoid the conversion to an array with wrong dtype detour. |
Sorry, something went wrong.
I like that idea.
Yes, and also do the conversion to with asanyarray that is wanted anyway.
Hmm, I should check, and if there aren't some already, add some test cases that ensure it remains consistent. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This is a follow-up to #32040 (comment), where I suggested that once we start treating str properly as a scalar for StringDType, we might be able to do some of the handling of it using _array_converter. It needs a small change to _array_converter (hence ping @seberg), but with it the code in strings.py does become somewhat simpler (especially for the T case).
Note that in principle it would be nice to have np.result_type(array, "string") work, just as is the case for np.result_type(array, 1.0). However, strings are already greedily interpreted as dtypes, so that doesn't work (goes to show that "conveniences" are not always a good idea). But _array_converter does not have that problem.
Opening as draft for now, since I'm not 100% sure this is the best approach (esp. for _array_converter, but also just in ensuring consistency between different numpy parts).
No AI.