Skip to content

Inconsistent dataclass order behavior on Python 3.13+ #137658

Open
Open
Inconsistent dataclass order behavior on Python 3.13+#137658
Labels
stdlibStandard Library Python modules in the Lib/ directorytopic-dataclassestype-bugAn unexpected behavior, bug, or error

Description

@gesslerpd
gesslerpd
opened on Aug 12, 2025

Bug report

Bug description:

Semantics of dataclasses __eq__ have changed in Python 3.13+, the semantic is now inconsistent with the order=True generated set of dunder methods on the same Python 3.13+ versions.

Related issues:
#128294
#120645

@dataclasses.dataclass(order=True)
class Data:
    a: float

nan = float("nan")

assert not (Data(nan) < Data(nan))
# assert not (Data(nan) <= Data(nan)), "fails on 3.13 even though {<, ==} are both False"
assert not (Data(nan) > Data(nan))
# assert not (Data(nan) >= Data(nan)), "fails on 3.13 even though {>, ==} are both False"
assert (Data(nan) != Data(nan))
assert not (Data(nan) == Data(nan))

Proposed fix PR: #137497

CPython versions tested on:

3.13

Operating systems tested on:

Windows

Linked PRs

Activity

  1. gesslerpd
    added
    type-bugAn unexpected behavior, bug, or error
    on Aug 12, 2025
  2. StanFromIreland
    added
    topic-dataclasses
    stdlibStandard Library Python modules in the Lib/ directory
    on Aug 12, 2025

  3. ericvsmith commented on Sep 19, 2025

    @ericvsmith
    ericvsmith
    on Sep 19, 2025
    Member

    Can you please show code where the values of comparisons change as a result of this PR? I presume they're all NaN related, or values with equally wacky comparison methods. But I'd like any actual change in semantics to be noted.

  4. gesslerpd commented on Sep 24, 2025

    @gesslerpd
    gesslerpd
    on Sep 24, 2025
    ContributorAuthor

    @ericvsmith Yes related to weird NaN-like objects, in the example code above the commented out lines will fail. Added similar tests to the PR that pass for this scenario, but generally the PR writes the order methods in a way more consistent with the current accepted semantics of __eq__ after it was optimized.

    Ever since semantics of __eq__ changed in 3.13+ the order methods have still been using the direct tuple semantics causing a slight misalignment shown in this issue.

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

    stdlibStandard Library Python modules in the Lib/ directorytopic-dataclassestype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions