expand_dims creates object dtype for string coordinates instead of inferring string dtype
#11038
Replies: 2 comments
This comment was marked as spam.
This comment was marked as spam.
-
|
Closing this since the issue is being tracked in #11061 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
expand_dimscreatesobjectdtype for string coordinates instead of inferring string dtypeSummary
When creating string coordinates,
expand_dimsproducesobjectdtype while other methods (DataArrayconstructor,assign_coords) correctly infer Unicode string dtype (<U*). This inconsistency is hard to detect and can cause subtle bugs.Minimal reproducible example
Output:
Why this is problematic
1. The mismatch is invisible
equals()andidentical()both returnTrue, hiding the dtype difference:Even element-wise comparison passes:
Only explicit dtype inspection reveals the issue:
2.
objectdtype propagates throughconcatWhen concatenating, any
objectdtype "infects" the result:Expected behavior
expand_dimsshould infer string dtype from string inputs, consistent with using the constructor, or usingassign_coords:Current workaround
Explicitly reassign coordinates after
expand_dims:Environment
Version info
Beta Was this translation helpful? Give feedback.
All reactions