Skip to content

BUG: same_kind casting between strings and bytes is inconsistent #32880

Open

Description

@mhvk

Describe the issue:

I would have expected that the different unicode strings could be casted to each other with "same_kind", but not to and from bytes (since really they are not the same kind). Oddly, however, casting strings to bytes is always possible, but the reverse is not possible for U to S.

Found while commenting on #32757

Reproduce the code example:

import numpy as np
s = np.array(b"a", dtype="S")
u = np.array("a", dtype="U")
t = np.array("a", dtype="T")

# U->S
np.can_cast(u.dtype, s.dtype, casting="same_kind")
# False  # Seems logical
u.astype(s.dtype, casting="same_kind")
# TypeError: Cannot cast scalar from dtype('<U1') to dtype('S1') according to the rule 'same_kind'
# OK consistent
# S->U
np.can_cast(s.dtype, u.dtype, casting="same_kind")
# True  # Huh, not the same?
s.astype(u.dtype, casting="same_kind")
# array('a', dtype='<U1')
# Why does this work?

# T->S
np.can_cast(t.dtype, s.dtype, casting="same_kind")
# True  # Huh? Why different from U->S?
t.astype(s.dtype, casting="same_kind")
# array(b'a', dtype='|S1')
# S->T
np.can_cast(s.dtype, t.dtype, casting="same_kind")
# True
s.astype(t.dtype, casting="same_kind")
# array('a', dtype=StringDType())

Error message:

Python and NumPy Versions:

2.6.0.dev0+git20261005.414e69e
3.14.7 (main, Sep 13 2026, 08:30:29) [GCC 16.2.0]

Runtime Environment:

  • numpy_version: 2.6.0.dev0+git20261005.414e69e
    python: 3.14.7 (main, Sep 13 2026, 08:30:29) [GCC 16.2.0]
    uname:
    machine: x86_64
    node: dolphin
    processor: ''
    release: 7.1.13+deb14-amd64
    system: Linux
    version: 'Misc #1 SMP PREEMPT_DYNAMIC Debian 7.1.13-1 (2026-09-03)'
  • simd_extensions:
    baseline:
    • X86_V2
      found:
    • X86_V3
      not_found:
    • X86_V4
    • AVX512_ICL
    • AVX512_SPR
  • ignore_floating_point_errors_in_matmul: false

How does this issue affect you or how did you find it:

No response

Activity

  1. Yvsd1234 commented on Oct 5, 2026

    @Yvsd1234
  2. ananyadas1803git commented on Oct 11, 2026

    @ananyadas1803git
  3. ngoldbaum commented on Oct 13, 2026

    @ngoldbaum
    Member

    This is a very complicated issue and is not a good first issue. Also we don't claim issues and I've hidden the comments above doing that.

  4. ngoldbaum commented on Oct 13, 2026

    @ngoldbaum
    Member

    @mhvk I think the best we can do for now is deprecate these conversions. Astropy at least relies on them in a few spots. I'll be updating #32757 to start a deprecation cycle for this behavior as well as sending in an AstroPy PRs to no longer rely on implicit bytes/text conversions in NumPy.

  5. mhvk commented on Oct 14, 2026

    @mhvk
    ContributorAuthor

    @ngoldbaum - yes, that makes sense. This has been the case for long enough that we should go slowly.

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions