FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

MAINT: treat str special in _array_converter and use it in strings.py by mhvk · Pull Request #32297 · numpy/numpy · GitHub

/ numpy Public

MAINT: treat str special in _array_converter and use it in strings.py - #32297

Draft
mhvk wants to merge 1 commit into
numpy:mainfrom
mhvk:array_converter_special_case_str
Draft

MAINT: treat str special in _array_converter and use it in strings.py#32297
mhvk wants to merge 1 commit into
numpy:mainfrom
mhvk:array_converter_special_case_str

Conversation

mhvk commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

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.

seberg commented Aug 26, 2026

Copy link
Copy Markdown
Member

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)

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.
(I am not immediately sure how dtype discovery works here, did the array-converter actually skip converting to a full array for Ptyhon scalars? As it still needs to discover the string length, unfortunately.)

mhvk commented Aug 26, 2026

Copy link
Copy Markdown
Contributor Author

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)

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.

I like that idea.

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.

Yes, and also do the conversion to with asanyarray that is wanted anyway.

(I am not immediately sure how dtype discovery works here, did the array-converter actually skip converting to a full array for Ptyhon scalars? As it still needs to discover the string length, unfortunately.)

Hmm, I should check, and if there aren't some already, add some test cases that ensure it remains consistent.

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants


Back | FazBrowse Home | New Git URL