Detect redundant type conversion

[simon-liebehenschel]

Bad example 1

def filter_vertices(ids: list[int]):
    ...

ids = [1, 2, 3]
filter_vertices(
    list(ids)   # A redundant type conversion. This was already a list.
)

Bad example 2

def find_users(names: Iterable[str]):  # Accepts tuples, lists, sets, etc. It does not care.
    ...

names = ("John", "Bob", "Sam",)
find_users(
    list(names)   # A redundant `list()` call because the function does not care what it iterates.
)

Bad example 3

foo = 42
bar = int(foo)  # A redundant `int()` call; the value is already `int`.

Open questions

• Are there any related issues or discussions? I found none.
• How hard is to detect this?

[Rich Chiodo (rchiodo)]

My guess this is not something Pyright would do. This is not really a type checking scenario, but more of a linting scenario. You're not doing anything that is wrong, just redundant.

[simon-liebehenschel]

My guess is this is not something Pyright would do. This is not really a type checking scenario, but more of a linting scenario. You're not doing anything wrong, just redundant.

Rich Chiodo (@rchiodo) Thank you for your reply.

I agree with the following points:

• This is not something Pyright would do.
• This is not really a type checking scenario, but more of a linting scenario.

However, note that redundant conversions shift from "not wrong, just redundant" to becoming a performance bottleneck on a hot path when you need to work with data-heavy pipelines and thousands of users.

I will close this discussion for now.

---

UPDATE: I've found this is already implemented by Pyrefly: https://pyrefly.org/en/docs/error-kinds/#unnecessary-type-conversion