Repository navigation
gh-159184: Do not compare set elements when marshalling a set - #159196
Merged
Merged
Conversation
gpshead
added
needs backport to 3.14
Set elements are written in the order of their dumps. They were sorted as (dump, element) pairs, so elements with the same dump were compared. That raised TypeError for a set of several complex NaNs, which the compiler can produce by constant folding, making the module impossible to marshal. Sort (dump, index, element) tuples, in which the indexes are all different. Elements with the same dump stay in the order of the set, as float NaNs did before.
gpshead
force-pushed
the
marshal-set-sort-bytes
branch
from
October 11, 2026 22:00
9ae5920 to
910690f
Compare
|
Thanks @gpshead for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14, 3.15. |
|
Sorry, @gpshead, I could not cleanly backport this to Please backport manually with cherry_picker, see the devguide for more information. |
|
Sorry, @gpshead, I could not cleanly backport this to Please backport manually with cherry_picker, see the devguide for more information. |
|
GH-159205 is a backport of this pull request to the 3.15 branch. |
|
GH-159206 is a backport of this pull request to the 3.14 branch. |
gpshead
added a commit
that referenced
this pull request
Oct 11, 2026
…H-159196) (#159206) Set elements are written in the order of their dumps. They were sorted as (dump, element) pairs, so elements with the same dump were compared. That failed for a set of several complex NaNs, which the compiler can produce by constant folding, making the module impossible to marshal. On this branch the failure was reported as MemoryError. Sort (dump, index, element) tuples, in which the indexes are all different. Elements with the same dump stay in the order of the set, as float NaNs did before. (cherry picked from commit 1967a87)
gpshead
added a commit
that referenced
this pull request
Oct 11, 2026
…H-159196) (#159205) Set elements are written in the order of their dumps. They were sorted as (dump, element) pairs, so elements with the same dump were compared. That failed for a set of several complex NaNs, which the compiler can produce by constant folding, making the module impossible to marshal. On this branch the failure was reported as MemoryError. Sort (dump, index, element) tuples, in which the indexes are all different. Elements with the same dump stay in the order of the set, as float NaNs did before. (cherry picked from commit 1967a87)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
marshalwrites the elements of a set in the order of their dumps, so that the output does not depend on hash order. It did that by sorting(dump, element)pairs, which compares the elements whenever two of them have the same dump. That happens for NaNs that are distinct objects, and complex numbers cannot be ordered:Change
flowchart TB subgraph before["main"] direction TB b1["list of (dump, element)"] --> b2["PyList_Sort()"] b2 --> b3{"equal dumps?"} b3 -- no --> b4["ordered by dump"] b3 -- yes --> b5["compares the elements"] b5 -- complex --> b6["TypeError"] b5 -- "float NaN" --> b7["neither is smaller:<br>left in set order"] end subgraph after["this PR"] direction TB a1["list of (dump, index, element)<br>index = position in the set"] --> a2["PyList_Sort()"] a2 --> a3{"equal dumps?"} a3 -- no --> a4["ordered by dump"] a3 -- yes --> a5["compares the indexes,<br>which always differ:<br>left in set order"] endThe output is unchanged wherever marshalling worked before: elements with different dumps are ordered by dump, and float NaNs with equal dumps stay in set order as they did. The only difference is that elements are never compared.
This is the small part of gh-159184 that can be backported. The other part, that the order of elements with equal dumps follows their addresses, needs #159192 and is a separate PR.
This touches the same block as the PR for gh-159185; whichever is merged second needs a one-line conflict resolved.
Tests
test_unorderable_set_itemsandtest_unorderable_set_items_in_codereplacetest_error_in_set_item, which asserted theTypeError.