[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

On Tue, 31 Aug 2021, 2:52 am Brett Cannon, wrote:

On Sun, Aug 29, 2021 at 2:01 PM Serhiy Storchaka wrote:

...

...

So my question is whether the discrepancy between what `async for` expects and what `aiter()` expects on purpose? https://bugs.python.org/issue31861 https://bugs.python.org/issue31861 was the issue for creating aiter() and I didn't notice a discussion of this difference. The key reason I'm asking is this does cause a deviation compared to the relationship between `for` and `iter()` (which does not require `__iter__` to be defined on the iterator, although collections.abc.Iterator does). It also makes the glossary definition being linked from

https://docs.python.org/3.10/reference/compound_stmts.html#the-async-for-sta...

...

< https://docs.python.org/3.10/reference/compound_stmts.html#the-async-for-sta...

incorrect.

PyIter_Check() only checks existence of __next__, not __iter__ (perhaps for performance reasons).

Or maybe no one thought to require __iter__ for iterators?

I don't think PyIter_Check is testing the formal definition of an iterator, I think it's just testing if calling __iter__ can be skipped (as you say, for performance reasons). I'm surprised iter() would skip calling __iter__ just because an object defines __next__, though. Even though "__iter__ is defined and returns self" is part of the iterator definition, it still feels like a leap from there to "if __next__ is defined, skip calling __iter__ in iter()". The optimisation that bypasses the __[a]iter__ method call feels more legitimate in the actual for loop syntax, it just feels odd to me if the builtin isn't forcing the call. Cheers, Nick.