refactor: improve type hints in linear_search.py

[jlaportebot]

Describe your change:

Improved type hints in searches/linear_search.py to better support searching for any comparable type, not just integers.

• Add an algorithm?
• Fix a bug or typo in an existing algorithm?
• Add or change doctests? -- Note: Please avoid changing both code and tests in a single pull request.
• Documentation change?

Checklist:

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized.
• I know that pull requests will not be merged if they fail the automated tests.
• This PR only changes one algorithm file. To ease review, please open separate PRs for separate algorithms.
• All new Python files are placed inside an existing directory.
• All filenames are in all lowercase characters with no spaces or dashes.
• All functions and variable names follow Python naming conventions.
• All function parameters and return values are annotated with Python type hints.
• All functions have doctests that pass the automated testing.
• All new algorithms include at least one URL that points to Wikipedia or another similar explanation.
• If this pull request resolves one or more open issues then the description above includes the issue number(s) with a closing keyword: "Fixes #ISSUE-NUMBER".

Fixes #14592

[jlaportebot]

@cla-assistant please recheck

[TTAAAN]

This is already a good approach. using list[Any] aligns with the documentation as it expects a generic type.

However, Any allows the user to pass in any type which is correct, but there's an edge case. What if the user passes in [1, 2, "3", [1, 2]]? Type checker wouldn't warn about this since it still falls under Any type.

A better type hint would be the generic type T = TypeVar("T") since it enforces the type consistency at the type-checking level.

Furthermore, the documentation expects a collection with comparable items. A better type hint would be Sequence instead of list. The current implementation would cause a type checker warning if the user tries to pass a tuple (1, 2, 5, 0).

Overall, I suggest changing it to Sequence[T].

[jlaportebot]

Thanks @TTAAAN for the suggestion! I've updated the type hints to use Sequence[T] with TypeVar instead of list[Any], which provides better type consistency and also allows the functions to accept tuples and other sequence types. The changes are now pushed to this branch.

[TTAAAN]

Great progress. Actually I was exploring the codebase inside searching algorithm folder. I've found a stricter implementation from jump_search.py, the file used Protocol. Example implementation could be:

class Comparable(Protocol):
    def __lt__(self, other: Any, /) -> bool: ...

T = TypeVar("T", bound=Comparable)

This forces the type checker to additionally check if the type implements the method defined.

Furthermore, one of the test failed due to formatting issue, you could perform ruff check first before committing. You could read more here @TheAlgorithms/Python/files/CONTRIBUTING.md

Output from the pre-commit.ci - pr https://results.pre-commit.ci/run/github/63476337/1778984861.m7iReo7ZQpG_iMTD5wUHsw

[jlaportebot]

Thanks @TTAAAN! I've updated the implementation to follow the same pattern as jump_search.py:

1. Added Comparable(Protocol) — This enforces that the type parameter implements __lt__, which is stricter than just TypeVar("T").
2. Switched to PEP 695 syntax — Using [T: Comparable] instead of T = TypeVar("T") for cleaner type parameter declarations.
3. Used collections.abc.Sequence — Per the codebase convention, importing from collections.abc instead of typing.
4. Fixed formatting — Ran ruff to ensure pre-commit checks pass.

The doctests all pass, and ruff check/format are clean. Let me know if any further changes are needed!