Many functions expect parameters that are iterable and do not care if they are actually lists. But, instead of importing typing.Iterable, one may be tempted to just use list[type] and call it a day.
Like list can be made generic in a type hint, why not allow me to use iter like that as well?
Instead of:
from typing import Iterable
def go(a: Iterable[int]) -> None:
for i in a:
print(i)
You can write:
def go(a: iter[int]) -> None: # or aiter[int]!
for i in a:
print(i)
# we could go even further for sync iterables?
def go(a: [int]) -> None:
for i in a:
print(i)
But one snag is that iter returns iterators, specifically. Thus, using it to type hint any kind of iterable is a little dubious. The analogy with list isn’t quite 1:1.
Semantically iter doesn’t make sense. This is a method, an instance of <class 'builtin_function_or_method'>. You want the type hint to be the name of a type. list[int] and Iterable[int] make sense.
We’ve talked about this before (and similarly, about making builtins.callable[...] mean Callable. But as the other posts in this thread call out, the analogy just isn’t that good.
To add to what’s already been said, it’s going to be unclear to users whether iter[T] means Iterable[T] or Iterator[T].
If you don’t already, you should be using an editor that has an auto-import feature so that when you type Iterable, it always you automatically add the line