To be clear, the docstring is explicitly disclaiming any ordering contract. If you're reading "unordered" as meaning "not reordered" (like a list or tuple, where the elements appear in insertion order), that's not what "unordered" means here. It means "arbitrary order". As it happens, the hashcodes of small integers correspond to their numerical values, (mostly, -1 is a special case), so if no collisions occur and the numbers are sequential, the ordering will often look like it was sorted in semi-numerical order, as in your case.

That doesn't mean it's performing sorting, it just means that's how the hashes happened to distribute themselves across the buckets in the set. A different test case with slightly more distributed numbers won't create the impression of sorting:

>>> print({-5, -1, 13, 17})
{17, -5, 13, -1}

For the record, I chose that case to use CPython implementation details to produce a really unordered result (all the numbers are bucketed mod 8 in a set that small, and this produces no collisions, with all values mod 8 different from the raw value). On other versions of CPython, or alternate interpreters, both your case and mine could easily come out differently.

Point is, this isn't a bug, just a quirk in the small int hash codes.

Steven: I think they thought it was sorted in some string-related way, explaining (to them) why -1 was out of place (mind you, if it were string sorted, -1 would come first since the minus sign is ASCIIbetically first, 19 would fall between 1 and 2, and 25 between 2 and 3, so it doesn't hold up).

There's no bug here.