Skip to content

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

@mhvk 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.

@mhvk mhvk added this to the 2.6.0 Release milestone Aug 14, 2026
@mhvk
mhvk requested review from ngoldbaum and seberg August 14, 2026 21:29
@mhvk mhvk mentioned this pull request Aug 14, 2026
Merged
@ngoldbaum ngoldbaum mentioned this pull request Aug 25, 2026
Open
@seberg

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

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.

@ngoldbaum ngoldbaum mentioned this pull request Sep 15, 2026
Open

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@seberg seberg Awaiting requested review from seberg
@ngoldbaum ngoldbaum Awaiting requested review from ngoldbaum

Assignees

No one assigned

Labels

03 - Maintenance component: numpy._core component: numpy.strings String dtypes and functions

Projects

None yet

Milestone

2.6.0 Release

Development

See More

Successfully merging this pull request may close these issues.

2 participants

@mhvk @seberg