TheAlgorithms/Python

This issue is only for those who are in the @TheAlgorithms/python_maintainers group. If you are not in that group, please do not leave a comment here. If you are in that group and have time to help us prepare for Hacktoberfest 2026, please pitch in... Please review and merge or close open pull requests. Even better, pick a directory in this repo and review and merge or close its open pull requests. @priya-sundaram-dev and I have been working feverishly to merge and close PRs, but we only have 16 days until October 1st. Issue #15310 tracks our progress, and I use scripts/pr_file_map.py to update the first entry. #15310 We will continue adding the on hold label to all new pull requests because our focus is on merging or closing older pull requests before October 1st. If you have recommendations (other than lowering our standards in CONTRIBUTING.md or mass-closing all pull requests), please leave them here or on Discord; DM me or @mention me. We should all be proud of the work we have

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

Summary Follow-up to #15180, which added an informational ty type-check job (.github/workflows/ty.yml, continue-on-error: true, ty check --exit-zero). This issue tracks what it takes to turn that advisory job into a required gate as type hints are added to the algorithms gradually, and records the current blockers. How the gradual baseline works today pyproject.toml [tool.ty] pins the interpreter and currently ignores 15 rules so the informational job starts from a green-ish baseline instead of drowning in noise: call-non-callable, deprecated, invalid-argument-type, invalid-assignment, invalid-parameter-default, invalid-return-type, invalid-type-arguments, invalid-type-form, no-matching-overload, not-iterable, not-subscriptable, parameter-already-assigned, unresolved-attribute, unresolved-import, unsupported-operator Requirements to "complete" the work The work is done rule-by-rule, matching how typing is added to the algorithms incrementally: Pick one ignored rule from the list abov

Repository commit 11d2a47 Python version (python --version) Python 3.11.7 Dependencies version (pip freeze) pytest>=8.4.1 pytest-cov>=6 Expected behavior topological_sort in graphs/kahns_algorithm_topo.py should perform BFS queue operations in $O(1)$ time using collections.deque.popleft(), maintaining the algorithm's overall time complexity of $O(V + E)$. topological_sort should handle valid graphs with sparse/non-contiguous integer vertex IDs (e.g., {10: [20], 20: []}) without crashing and return the correct topological ordering [10, 20]. Actual behavior $O(N)$ Dequeue Performance: Line 43 uses vertex = queue.pop(0) on a Python list. Deleting from the front of a list takes $O(N)$ time, degrading Kahn's algorithm from $O(V + E)$ to $O(V^2 + E)$. Crash on Non-Contiguous/Sparse Vertex IDs: Line 26 initializes indegree = [0] * len(graph), assuming vertex IDs are contiguous integers starting at 0 (0..N-1). Passing sparse vertex IDs like {10: [20], 20: []} results in indegree having

Repository commit 567bb93 Python version (python --version) Python 3.14.2 Dependencies version (pip freeze) contourpy==1.3.3 cycler==0.12.1 dnspython==2.8.0 fonttools==4.62.1 iniconfig==2.3.0 kiwisolver==1.5.0 matplotlib==3.10.8 numpy==2.4.4 packaging==26.0 pillow==12.2.0 pluggy==1.6.0 Pygments==2.20.0 pymongo==4.17.0 pyparsing==3.3.2 pytest==9.1.1 pytest-timeout==2.4.0 python-dateutil==2.9.0.post0 pyzmq==27.1.0 six==1.17.0 Expected behavior radix_sort() should raise a value error when a negative value is used. ex. radix_sort([1, 3, -2, 4]) should raise ValueError because a negative value will not map to the correct bucket. Actual behavior When provided a negative value, radix_sort() proceeds with sorting and returns an incorrectly sorted array. Ex. radix_sort([1, 3, -2, 4]) returns [1, 3, 4, -2] Place test_radix_sort.py in the same directory and run "pytest test_radix_sort.py" to replicate. This is a small bug, but violates the definition that "Algorithms should: ... raise Python exc