We have already merged it, the fix is part of the rc2.

yury

On Wed, Sep 8 2021 at 12:48 PM, Brett Cannon <brett@python.org> wrote:

On Thu, Sep 2, 2021 at 7:43 PM Yury Selivanov <yselivanov.ml@gmail.com> wrote:

Comments inlined:

On Thu, Sep 2, 2021 at 6:23 PM Guido van Rossum <guido@python.org> wrote:

First of all, we should ping Yury, who implemented `async for` about 6 years ago (see PEP 492), and Joshua Bronson, who implemented aiter() and anext() about 5 months ago (see https://bugs.python.org/issue31861). I've CC'ed them here.

Looks like PyAiter_Check was added along with the aiter/anext builtins. I agree it's unnecessary to check for __aiter__ in it, so I let's just fix it.

 

My own view:

A. iter() doesn't check that the thing returned implements __next__, because it's not needed -- iterators having an __iter__ methor is a convention, not a requirement.

Yeah.

 

You shouldn't implement __iter__ returning something that doesn't implement __iter__ itself, because then "for x in iter(a)" would fail even though "for x in a" works. But you get an error, and anyone who implements something like that (or uses it) deserves what they get. People know about this convention and the ABC enforces it, so in practice it will be very rare that someone gets bitten by this.

B. aiter() shouldn't need to check either, for exactly the same reason. I *suspect* (but do not know) that the extra check for the presence of __iter__ is simply an attempt by the implementer to enforce the convention. There is no *need* other than ensuring that "async for x in aiter(a)" works when "async for x in a" works.

I agree.

[SNIP]

 

Bottom line: let's fix PyAiter_Check to only look for __anext__. It's a new function so we can still fix it to reflect PyIter_Check and not worry about anything.

I don't know if Pablo wants such a change in 3.10 since we are at rc2 at this point, so this might have to wait for 3.11 (although there's no deprecation here since it's a loosening of requirements so it could go in straight away).