Skip to content

uint32 dataframe don't display in px.bar #4291

Description

@MarcoGorelli

Here's an example:

px.bar(
    pd.DataFrame({
        'break_point': [-7, -6., -5, -4, -3],
        'Rain_count': [0, 0, 6, 696, 31335],
    }).astype({'Rain_count': 'uint32'}),
    x='break_point',
    y='Rain_count'
)

image

If I change uint32 to int32, then it displays fine:

image

versions:

  • pandas: '2.0.3'
  • plotly '5.15.0'
  • jupyter: 3.6.3

Activity

  1. self-assigned this
    on Jul 11, 2024
  2. removed their assignment
    on Aug 2, 2024
  3. emilykl commented on Sep 1, 2026

    @emilykl
    Contributor

    Oddly enough, this seems to be an issue with the way px.bar() determines orientation! It seems to incorrectly decide that orientation should be "v" for these inputs, which causes the interpretations of x and y to be reversed. If you look very very closely, or zoom in, you can see very thin horizontal bars located at 0, 6, 696, and 31335 along the y-axis.

    Forcing orientation="v" results in the expected plot:
    Image

    Looks like the bug traces to the _is_continuous() function in plotly/express/_core.py, which evaluates to False in the case of Rain_count, causing Plotly Express to decide that Rain_count is the categorical array and should be treated as the bar labels.

    It seems the root cause is that dtype.kind for the Rain_count column is u, which is not one of "ifc".

    Plausibly we should just change "in "ifc" to in "ifcu" — @MarcoGorelli do you see any issue with that? Looks like that does resolve the issue.

    Numpy dtype.kind values: https://numpy.org/doc/stable/reference/generated/numpy.dtype.kind.html

  4. emilykl commented on Sep 1, 2026

    @emilykl
    Contributor

    I think this has the same root cause as #4344

  5. added a commit that references this issue on Sep 15, 2026
    f954c9f
  6. MarcoGorelli commented on Sep 19, 2026

    @MarcoGorelli
    ContributorAuthor

    Plausibly we should just change "in "ifc" to in "ifcu" — @MarcoGorelli do you see any issue with that? Looks like that does resolve the issue.

    Numpy dtype.kind values: https://numpy.org/doc/stable/reference/generated/numpy.dtype.kind.html

    Sorry for the delay, but yes, that looks fine, thanks 🙏

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3backlogbugsomething broken

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions