Improve TypeError error message when trying to iterate over an object of type 'int'

[vladimirrotariu]

Feature or enhancement

Proposal:

Currently, in situations like

count = 10
for _ in count:
    pass

or the analogous list comprehension situation, the error message of the ensuing TypeError is
'int' object is not iterable

The improved error message would look like:
'int' object is not iterable. Did you mean: 'range('int')'?

The original TypeError error message 'int' object is not iterable results from other prohibited operations as well, such as

{1, *1, 0, 4}

in which case the proposed suggestion is irrelevant. However, based on searching on StackOverflow "'int' object is not iterable", the majority of issues fall into the first situation.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

It is fairly common to try to iterate over an object of type int. Here you may find some guiding links with examples:

Simple for loops:
https://www.codecademy.com/forum_questions/54f231c876b8fe4269002f2f
https://stackoverflow.com/questions/43425270/typeerror-int-object-is-not-iterable
https://blog.arrowhitech.com/typeerror-int-object-is-not-iterable-in-python-what-is-it-and-solution/
List comprehensions:
https://stackoverflow.com/questions/32312371/typeerror-int-object-is-not-iterable

Also, when I searched for "TypeError: 'int' object is not iterable" on StackOverflow, I got the impression that the majority of the issues might be solved with "range('int')", see here:
https://stackoverflow.com/search?q=TypeError%3A+%27int%27+object+is+not+iterable

Linked PRs

• gh-118598: Improve suggestion of TypeError when attempting to iterate over an integer #118601
• gh-118598: Improve suggestion of TypeError when attempting to iterate over an integer #118602

[sobolevn]

Hi! Thanks for the issue.

However, based on searching on StackOverflow "'int' object is not iterable", the majority of issues fall into the first situation.

I think we cannot make this assumption blindly.

In many cases range(some_int) might not be a proper solution:

• You might want to use a different name, when some_int is just a typo
• range might be redefined to something else in this namespace
• What if some_int is 0 or negative?

>>> list(range(0))
[]
>>> list(range(-1))
[]

• What if you want some a bit different range? Like range(1, some_int) or range(some_int + 1)?

I would like not to recommend range in the general case.

Maybe start with a discussion on https://discuss.python.org ?

[gaogaotiantian]

I agree with @sobolevn , this is a change that might introduce a lot of false positive. I agree that may new users probably have had the issue you mentioned, but your solution is too broad.

For example any(1) would create the exact same error message, and converting that to range() is obviously not reasonable. There are just too many cases where an integer could be accidentally used as an iterable and it's not safe to assume the case is when it's being used in a for loop.

Also, your fix checks the exception string for such case, which would also be a bit hacky.

Overall I believe this change has a too large unwanted impact, and I also agree that this should be discussed on dpo first.

[terryjreedy]

Add fix hints to exception messages, as here;

>>> mylist = [1,2]
>>> for i in mylis: pass
...
NameError: name 'mylis' is not defined. Did you mean: 'mylist'?

was started just a few versions ago. I agree with others that proposal/patch as is is too broad.
@pablogsal Is restricting hint to where relevant possible?