False negative 'for-any-all' when there is a break or a pre-initialized boolean

[Pierre-Sassoulas]

Current problem

def optimized_any_with_break(split_lines: list[str], max_chars: int) -> bool:
    """False negative found in https://github.com/PyCQA/pylint/pull/7697"""
    potential_line_length_warning = False
    for line in split_lines:  # [consider-using-any-or-all]
        if len(line) > max_chars:
            potential_line_length_warning = True
            break
    return potential_line_length_warning

Can be simplified to

def optimized_any_with_break(split_lines: list[str], max_chars: int) -> bool:
    return any(len(line) > max_chars for line in split_lines)

Desired solution

for-any-all raised in this case.

Additional context

I did not think very hard about potential false positive, but I think it make sense to not raise if potential_line_length_warning is not initialized directly above the for loop.

[clavedeluna]

I can take a look at this and see if I can come up with any false positives while changing the code.

[clavedeluna]

I would assume this test case should not raise the message, given that it doesn't mimic the behavior of any if break is removed

def optimized_any_without_break(split_lines, max_chars):
    potential_line_length_warning = False
    for line in split_lines:
        if len(line) > max_chars:
            potential_line_length_warning = True
    return potential_line_length_warning

[Pierre-Sassoulas]

I think it should raise, the break version is just a verbose way to do any/all but the code without the break benefit from this check even more ! (There should not be anything else in the for loop though) What do you think @areveny ?

[clavedeluna]

started a draft PR to help iterate over any new test cases.

[areveny]

I think these cases, with and without break, all make a lot of sense for raising the message. The draft PR looks good so far.