Is python's sorted() function guaranteed to be stable?
Question:
The documentation doesn’t guarantee that. Is there any other place that it is documented?
I’m guessing it might be stable since the sort method on lists is guaranteed to be stable (Notes 9th point: “Starting with Python 2.3, the sort() method is guaranteed to be stable”), and sorted is functionally similar. However, I’m not able to find any definitive source that says so.
Purpose: I need to sort based on a primary key and also a secondary key in cases where the primary key is equal in both records. If sorted() is guaranteed to be stable, I can sort on the secondary key, then sort on the primary key and get the result I need.
PS: To avoid any confusion, I’m using stable in the sense of “a sort is stable if it guarantees not to change the relative order of elements that compare equal”.
Answers:
Yes, the intention of the manual is indeed to guarantee that sorted is stable and indeed that it uses exactly the same algorithm as the sort method. I do realize that the docs aren’t 100% clear about this identity; doc patches are always happily accepted!
The “What’s New” docs for Python 2.4 effectively make the point that sorted() first creates a list, then calls sort() on it, providing you with the guarantee you need though not in the “official” docs. You could also just check the source, if you’re really concerned.
They are stable.
By the way: you sometimes can ignore knowing whether sort and sorted are stable, by combining a multi-pass sort in a single-pass one.
For example, if you want to sort objects based on their last_name, first_name attributes, you can do it in one pass:
sorted_list= sorted(
your_sequence_of_items,
key= lambda item: (item.last_name, item.first_name))
taking advantage of tuple comparison.
This answer, as-is, covers the original question. For further sorting-related questions, there is the Python Sorting How-To.
The documentation changed in the meantime (relevant commit) and the current documentation of sorted explicitly guarantees it:
The built-in sorted() function is guaranteed to be stable. A sort is stable if it guarantees not to change the relative order of elements that compare equal — this is helpful for sorting in multiple passes (for example, sort by department, then by salary grade).
This part of the documentation was added to Python 2.7 and Python 3.4(+) so any compliant implementation of that language version should have a stable sorted.
Note that for CPython the list.sort has been stable since Python 2.3
- Tim Peters rewrote his
list.sort() implementation – this one is a “stable sort” (equal inputs appear in the same order in the output) and faster than before.
I’m not 100% sure on sorted, nowadays it simple uses list.sort, but I haven’t checked the history for that. But it’s likely that it “always” used list.sort.
The Python 3.6 doc on sorting now states that
Sorts are guaranteed to be stable
Furthermore, in that document, there is a link to the stable Timsort, which states that
Timsort has been Python’s standard sorting algorithm since version 2.3
The documentation doesn’t guarantee that. Is there any other place that it is documented?
I’m guessing it might be stable since the sort method on lists is guaranteed to be stable (Notes 9th point: “Starting with Python 2.3, the sort() method is guaranteed to be stable”), and sorted is functionally similar. However, I’m not able to find any definitive source that says so.
Purpose: I need to sort based on a primary key and also a secondary key in cases where the primary key is equal in both records. If sorted() is guaranteed to be stable, I can sort on the secondary key, then sort on the primary key and get the result I need.
PS: To avoid any confusion, I’m using stable in the sense of “a sort is stable if it guarantees not to change the relative order of elements that compare equal”.
Yes, the intention of the manual is indeed to guarantee that sorted is stable and indeed that it uses exactly the same algorithm as the sort method. I do realize that the docs aren’t 100% clear about this identity; doc patches are always happily accepted!
The “What’s New” docs for Python 2.4 effectively make the point that sorted() first creates a list, then calls sort() on it, providing you with the guarantee you need though not in the “official” docs. You could also just check the source, if you’re really concerned.
They are stable.
By the way: you sometimes can ignore knowing whether sort and sorted are stable, by combining a multi-pass sort in a single-pass one.
For example, if you want to sort objects based on their last_name, first_name attributes, you can do it in one pass:
sorted_list= sorted(
your_sequence_of_items,
key= lambda item: (item.last_name, item.first_name))
taking advantage of tuple comparison.
This answer, as-is, covers the original question. For further sorting-related questions, there is the Python Sorting How-To.
The documentation changed in the meantime (relevant commit) and the current documentation of sorted explicitly guarantees it:
The built-in
sorted()function is guaranteed to be stable. A sort is stable if it guarantees not to change the relative order of elements that compare equal — this is helpful for sorting in multiple passes (for example, sort by department, then by salary grade).
This part of the documentation was added to Python 2.7 and Python 3.4(+) so any compliant implementation of that language version should have a stable sorted.
Note that for CPython the list.sort has been stable since Python 2.3
- Tim Peters rewrote his
list.sort()implementation – this one is a “stable sort” (equal inputs appear in the same order in the output) and faster than before.
I’m not 100% sure on sorted, nowadays it simple uses list.sort, but I haven’t checked the history for that. But it’s likely that it “always” used list.sort.
The Python 3.6 doc on sorting now states that
Sorts are guaranteed to be stable
Furthermore, in that document, there is a link to the stable Timsort, which states that
Timsort has been Python’s standard sorting algorithm since version 2.3