Ideas for new lints around iteration

[alexprengere]

I apologize if you not looking for new lints to implement in Ruff.

I do a fair share of code reviews, and I quite often stumble on these issues which are not caught by any linter AFAICT (flake8, pylint, refurb, ruff). I am not sure how hard those would be to implement, as for the first one you would need some type inference.

a = [1, 2]
b = [3, 4]

# Not good
for x in a + b:
    print(x)

# Better but not really good either
for x in *a, *b:
    print(x)

# Best
for x in itertools.chain(a, b):
    print(x)

This happens really often when people want to iterate on multiple lists, tuples, etc.
Another one in a similar spirit:

a = [1, 2]
b = [3, 4]
c = [a, b]

# Not good
for x in itertools.chain(*c):
    print(x)

# Better
for x in itertools.chain.from_iterable(c):
    print(x)

[charliermarsh]

Thanks! One question -- given:

# Not good
for x in a + b:
    print(x)

When would it be invalid to rewrite as itertools.chain(a, b)?

[alexprengere]

If you are sure a and b are lists or tuples, I think it is never invalid to rewrite.
It can be invalid on classes that would be iterable but also implement some type of addition that is not concatenation, like a numpy matrix:

import numpy as np

a = b = np.matrix([[1,2], [3,4]])

for x in a + b:
    print(x)
# [[2 4]]
# [[6 8]]

for x in itertools.chain(a, b):
    print(x)
# [[1 2]]
# [[3 4]]
# [[1 2]]
# [[3 4]]

[charliermarsh]

Thanks, that makes sense. We do have the ability to do limited within-file inference for lists, tuples, sets, and dictionaries, with the downside that the inference can lead to false-negatives (but is a reasonable fit for rules like this).

[Skylion007]

flake8-simplify or flake8-comprehensions may be interested in this rule as well.

[Avasam]

Idk how complete it is, but refurb added itertool.chain related checks lately: dosisod/refurb#293