I think that iter is different from dict / list / etc, because iter is a function, not a class.

As far as I know, we don't have any generic functions at the moment.

Agree with Nikita. Someone previously suggested callable[args, ret] as a substitute for collections.abc.Callable/typing.Callable too and we rejected it. See the reasoning at #86268.

I'm also not a fan of this idea. iter is a function that produces instances of collections.abc.Iterator, but it isn't the same thing as collections.abc.Iterator. Overloading it more like this would just lead to confusion, in my opinion.

Interesting discussion. I came across this from #86268 while relearning type hints post typing module deprecation,.

One difference I could appreciate is that unlike dict/list, collection.abc.Iterator is not a concrete class, and thus should not be instantiated; hence iter() cannot be a construtor for the class (and thus currently it is not); it is something that always returns a subclass of Iterator.

The confusion I can construct is when we try to annotate the iter function itself after this proposal:

def iter[T](obj : T) -> abc.Iterator[getElementType(T)]

becomes

type iter[E] = abc.Iterator[E]
def iter[T](obj: T) -> iter[getElementType(T)]

This does look strange,(and the lack of facility for getElementType(T) makes it worse) but the two use of [] are different: the first [T] is a type parameter, and the second [] an object type hint, and we most likely already make that distinction for other use of type parameters.

Is this a severe enough confusion, or are there more severe confusions beyond this one?

I have some discussion of this idea at https://jellezijlstra.github.io/why-cant-we#builtin-functions-as-type-expressions