Enhance aiter to support built-in sync iterables

[Henkhogan]

Feature or enhancement

Enhance builtin iterables like list, range with async methods like aiter, anext,...

Pitch

It would allow to use e.g. async list comprehenions on normal lists like:

[_ async for _ in list(range(1,10))]

-> helpful if the code snipped is supposed to handle async iterables like normal iterables

Previous discussion

https://discuss.python.org/t/enhance-builtin-iterables-like-list-range-with-async-methods-like-aiter-anext/21352/1

Linked PRs

• GH-101495: Allow aiter() to be passed non-async iterables #119278

[ofek]

I am very much in favor of this as it would remove the need to pepper the use of the following utility throughout every code base:

async def aiter(iterable: Iterable):
    for item in iterable:
        yield item

[zware]

As mentioned in the discussion, sprinkling __aiter__ implementations around the codebase is not the way to go here. Adjusting the aiter builtin to automatically wrap synchronous iterators is a much more palatable option.

[ethanfurman]

Is adding __aiter__ to object feasible?

[brettcannon]

Is adding __aiter__ to object feasible?

Feasible, yes. Desirable, no, as that would make every object an asynchronous iterable.

[kumaraditya303]

I am -1 on this, to me this feels like an anti pattern and if you are using async generator for sync code then IMO it is wrong design.

[merwok]

Some motivation was provided in the thread, and the current proposal is about changing aiter rather than built-in objects.

[ofek]

Yes, can we change the PR title?

[Henkhogan]

Should this be extended to "async with" which seems very similar to me

[zware]

Should this be extended to "async with" which seems very similar to me

Not in this issue, but perhaps in another. It has different considerations and is completely unrelated to this issue.

[SimpleArt]

It is worth noting that async-stdlib includes this function, which can serve as a reference implementation.

This does however beg me the question: is it aiter that needs to be changed or the semantics of using async for? It sounds like we're going from async for x in iterable to using async for x in aiter(iterable) everywhere. This situation is also similar to iter(...) and types which implement __getitem__ and __len__. Note that there's no need to do for x in iterable in those cases either. Ideally if async for itself is changed, then one can simply think of aiter as async for x in iterable: yield x, so it should resolve this case as well.

[merwok]

In general, Python’s design is that keyword and operators have clear, simple behaviour (async for iterates over async iterables) and functions can do convenient things and conversions (iter is more than just calling __iter__, aiter can wrap sync iterables).

[brettcannon]

It is worth noting that async-stdlib includes this function, which can serve as a reference implementation.

There are potential licensing concerns unless the person who wrote that code for async-stdlib also opens the PR to contribute the code to CPython.

is it aiter that needs to be changed or the semantics of using async for?

It's aiter.

It sounds like we're going from async for x in iterable to using async for x in aiter(iterable) everywhere.

That's only true if you accept any iterable, async or not, and want it to work in that loop.

[kumaraditya303]

The discussion died and I am still strong -1 to this, I suggest anyone interested taking this forward to get agreement on the semantics and work on a possible PEP. Closing as it is not actionable now.

[lambdaq]

Some motivation was provided in the thread, and the current proposal is about changing aiter rather than built-in objects.

This sounds like a good compromise, are there any shipping plans to update the built-in aiter() ?

[mjsir911]

@ericvsmith This is the issue (talking about this in pycon), probably will not open a pretty much duplicate issue of this feature proposal. Will pursue a PEP as per @kumaraditya303's suggestion