[Python-Dev] PEP 492: async/await in Python; version 4 (original) (raw)

Arnaud Delobelle arnodel at gmail.com
Sun May 3 20:59:03 CEST 2015

On 3 May 2015 at 16:24, Steven D'Aprano <steve at pearwood.info> wrote:

On Fri, May 01, 2015 at 09:24:47PM +0100, Arnaud Delobelle wrote:

I'm not convinced that allowing an object to be both a normal and an async iterator is a good thing. It could be a recipe for confusion. In what way? I'm thinking that the only confusion would be if you wrote "async for" instead of "for", or vice versa, and instead of getting an exception you got the (a)syncronous behaviour you didn't want.

Yes. This is the same kind of confusion that this PEP is trying hard to get rid of in other parts (i.e. the confusion between 'yield' and 'yield from' in current coroutines).

But I have no intuition for how likely it is that you could write an asyncronous for loop, leave out the async, and still have the code do something meaningful.

Well if you've made you object both iterable and 'async iterable' then it's very likely that you're going to get something meaningful out of either kind of iteration. Just not the way you want it if you mistakenly left out (or added) the 'async' keyword in your loop.

Other than that, I think it would be fine to have an object be both a syncronous and asyncronous iterator. You specify the behaviour you want by how you use it. We can already do that, e.g. unittest's assertRaises is both a test assertion and a context manager.

The latter is fine, because there is no danger of mistaking one for the other, unlike iterators and 'async iterators'.

But my argument is simply that there is no good reason to aim for the ability to have object conform to both protocols. So it shouldn't be a criterion when looking at the merits of a proposal. I may very well be wrong but I haven't yet seen a compelling case for an object implementing both protocols.

Cheers,

-- Arnaud

More information about the Python-Dev mailing list