Quicker way of type hinting Iterable

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)
4 Likes

I like it.

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.

Sounds great. But i’m not sure it always works.

@gooseontheloose you should join this new idea. READ ALL THE INFORMATION slowly

Because iter isn’t a type. What next, hex to mean a string that is prefixed with 0x and otherwise contains only hexadecimal digit symbols?

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].

10 Likes

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

from collections.abc import Iterable

Neovim, for example, does this.

I know I’m late, but I came across this thread while searching for the best way to annotate iterables, and I want to respectfully disagree with this reasoning:

I don’t like the idea that we “should” be using any sort of editor in order to have a pleasant experience with core language features. That seems contrary to my experience with Python, which I find concise enough that I can comfortably write it in vanilla vi (although I do use an IDE sometimes). It’s a big reason I find the language more joyful than, say, Java, which is arduous to write without smart auto-completion. I also believe it’s part of what makes Python so accessible to new programmers.

I’ve been happy to see other common types, like list[T] and T|None, become annotatable without any imports. Why should collections.abc.Iterable[T] be any different?

I understand that iter[T] is not the right answer, but I have hard time believing that we can’t figure some way to allow devs to annotate iterables without importing from the standard library.

1 Like

To annotate iterables, you would either need to use:

  • string annotations,
  • a new builtin, or
  • some new punctuation-annotation.

I don’t think new punctuation is going to be very popular. String annotations are bad for introspection and will hopefully be supplanted by PEP 649. So that leaves a new built-in. It’s very hard to add built-ins because it breaks existing code.

Fair opinion, but it is a common reply for feature requests like:

  • block comments (your editor should be able to add # to multiple lines.
  • bulk passing locals to a function f(a=a, b=b, c=c). Your editor should be able to fill in pairs of words.

Of course you’re right that it would be nice if you could program Python efficiently in notepad, for example. But making Python adapt to that has other costs. If you come up with something, definitely propose it :smile:

1 Like

While thoughts may differ, I don’t see typing as a core feature anymore than say itertools or pathlib. Having to import some more advanced features is commonplace in Python, why should the more advanced features of typing be any different?

You’re right, typing isn’t exactly a core feature.

That said, I think OP said it best:

Whether or not typing is a core feature, lists can be generically annotated without importing anything, and iterables can’t, which softly nudges developers to use list even when collections.abc.Iterable would suffice (which, in my experience, is very often).

I’m not sure what the right solution is. I understand that adding an Iterable builtin solely for the purpose of type annotation would be unprecedented. I am interested in what punctuation could look like (before you scoff, consider that Python syntax is already steeped with the concept of iterables, including for..in and *), but I’m not familiar enough yet with the internals of annotations to make an informed proposal.