Many of our sorts/ implementations are written and tested only against list[int], even though most comparison sorts work for any items that support <. This issue collects the small, well-scoped changes that make them correctly typed and tested for the general case — a good batch of beginner-friendly PRs for Hacktoberfest.
The type hint to use
Comparison sorts need items that are orderable, not Any. Model that with a small Protocol and a TypeVar bound to it:
from typing import Protocol
class Comparable(Protocol):
def __lt__(self, other: object, /) -> bool: ...
def bubble_sort[T: Comparable](collection: list[T]) -> list[T]:
...
list[T] (with T bound to Comparable) is more precise than list[Any]: it says "a list of items that can be compared with each other" and preserves the element type in the return.
Note: counting/radix/bucket/pigeonhole sorts are not comparison sorts — they rely on integer keys. Those should keep their integer-specific hints and are out of scope here.
The tests to add
For each comparison sort, cover a comparable non-int type and the failure mode. Add both a doctest and a case in tests/test_sorts.py:
# succeeds: strings are comparable
assert bubble_sort(["c", "a", "b"]) == ["a", "b", "c"]
# succeeds: floats are comparable
assert bubble_sort([2.5, -1.0, 0.0]) == [-1.0, 0.0, 2.5]
# raises: mixing non-comparable types must not silently mis-sort
import pytest
with pytest.raises(TypeError):
bubble_sort([1, "a"]) # '<' not supported between int and str
The TypeError case matters: a sort that "succeeds" on non-comparable input is a correctness bug, so the test should assert the exception rather than a result.
How to contribute
- Pick one comparison sort from
sorts/ (comment which one so we don't double up).
- Switch
Any → the Comparable/TypeVar pattern above.
- Add the succeed + raise cases as doctests and to
tests/test_sorts.py.
- Keep it to one algorithm per PR so reviews stay quick.
- Link this issue without closing it: reference it as
Part of #15234 or Ref #15234 in your PR description — not Closes/Fixes/Resolves #15234. A closing keyword makes GitHub auto-close this umbrella issue when your PR merges, even though other checkboxes remain. This issue should stay open until every box is checked.
I'll help review these and update the checklist below. Refs #15081.
Sort algorithms that can sort any comparable items
Many of our
sorts/implementations are written and tested only againstlist[int], even though most comparison sorts work for any items that support<. This issue collects the small, well-scoped changes that make them correctly typed and tested for the general case — a good batch of beginner-friendly PRs for Hacktoberfest.The type hint to use
Comparison sorts need items that are orderable, not
Any. Model that with a smallProtocoland aTypeVarbound to it:list[T](withTbound toComparable) is more precise thanlist[Any]: it says "a list of items that can be compared with each other" and preserves the element type in the return.The tests to add
For each comparison sort, cover a comparable non-int type and the failure mode. Add both a doctest and a case in
tests/test_sorts.py:The
TypeErrorcase matters: a sort that "succeeds" on non-comparable input is a correctness bug, so the test should assert the exception rather than a result.How to contribute
sorts/(comment which one so we don't double up).Any→ theComparable/TypeVarpattern above.tests/test_sorts.py.Part of #15234orRef #15234in your PR description — notCloses/Fixes/Resolves #15234. A closing keyword makes GitHub auto-close this umbrella issue when your PR merges, even though other checkboxes remain. This issue should stay open until every box is checked.I'll help review these and update the checklist below. Refs #15081.
Sort algorithms that can sort any comparable items