Feature request - invoke `any`/`all` on non iterables

[orSolocate]

Current problem

Probably an extension to the existing not-an-iterable error message.

Looks pretty trivial, but could be very useful in cases we want to run any or all on a generator or list that is a return value of a function call that might also return None (e.g. in a side/error case). Running any(None) or all(None) causes Python to crush, the user might think the code is okay, without ever running the None case, and the error is discovered only in a later stage.

Pylint shows no errors (as far as I am concerned) for:

all(None)

any(None)


def create_list():
    if error_case():
      return None
    return [1, 2, 3]

all(create_list())
any(create_list())
for _ in create_list():
    pass

Desired solution

I think we have here 2 cases:

1. We know the value is non-iterable, then it is just an expansion of not-an-iterable for any and all. Since this also invokes not-an-iterable:

for _ in None:
    pass

Error description: same as in not-an-iterable: Non-iterable value %s is used in an iterating context .

2. In some cases we know the value is non-iterable, then we need an extended logic that could also be applicable to using the for keyboard, e.g.:

def create_list():
    if error_case():
      return None
    return [1, 2, 3]

for _ in create_list():
    pass

Error description: might be the same error name as not-an-iterable, but with different description: Non-iterable value %s might be used in an iterating context (emphasis on the might).

Additional context

Maybe there are more cases of a built in function that causes iteration apart from all/any/for. Note that we might want to split this issue into 2 issues:

1. Extension of not-an-iterable to any and all keyword.
2. Enhancing not-an-iterable implementation to include cases where we know the value could be non-iterable.

[zenlyj]

Thanks for the proposal, this enhancement seems useful

case 1:
agree with the extension to include any and all. And if we are planning to include built-ins, it may be worth considering constructors like set(iterable) and list(iterable) as well?

case 2:
imo, it might be clearer to users if a separate message name is used. We already have possibly-used-before-assignment and possibly-unused-variable, perhaps it can be possibly-not-an-iterable?

[orSolocate]

@zenlyj Thank you for putting thought into my idea.

So I believe we agree to split it up into 2 issues/PRs?

Case 1:
I agree that set and list should also be included. I believe for the same reason we should include the iter() built-in. what do you think?

Case 2:
I don't see why not, I didn't know about the possibly-XXX checkers. what others think about that?