Ron Adam wrote:

A waiter? or awaiter?

As in a-wait-ing an awaiter.

The waiter would be the function executing the await operator, not the thing it's operating on. In a restaurant, waiters wait on customers. But calling an awaitable object a "customer" doesn't seem right at all. -- Greg

On 1 May 2015 at 12:24, Andrew Barnert via Python-ideas wrote:

Anyway, if I understand the problem, the main confusion is that we use "coroutine" both to mean a thing that can be suspended and resumed, and a function that returns such a thing. Why not just "coroutine" and "coroutine function", just as with "generator" and "generator function".

That's the terminology in the asyncio docs I guess: https://docs.python.org/3/library/asyncio-task.html#coroutine ... except that there it is referring to decorated generator functions. That feels like a category error to me because coroutines are a generalisation a functions so if anything is the coroutine itself then it is the async def function rather than the object it returns but I guess if that's what's already being used.

If the issue is that there are other things that are coroutines besides the coroutine type... well, there are plenty of things that are iterators that are all of unrelated types, and has anyone ever been confused by that? (Of course people have been confused by iterator vs. iterable, but that's a different issue, and one that doesn't have a parallel here.)

There is no concrete "iterator" type. The use of iterator as a type is explicitly intended to refer to a range of different types of objects analogous to using an interface in Java. The PEP proposes at the same time that the word coroutine should be both a generic term for objects exposing a certain interface and also the term for a specific language construct: the function resulting from an async def statement. So if I say that something is a "coroutine" it's really not clear what that means. It could mean an an asyncio.coroutine generator function, it could mean an async def function or it could mean both. Worse it could mean the object returned by either of those types of functions. -- Oscar

On May 1, 2015, at 04:49, Oscar Benjamin wrote:

On 1 May 2015 at 12:24, Andrew Barnert via Python-ideas wrote:

...

Anyway, if I understand the problem, the main confusion is that we use "coroutine" both to mean a thing that can be suspended and resumed, and a function that returns such a thing. Why not just "coroutine" and "coroutine function", just as with "generator" and "generator function".

That's the terminology in the asyncio docs I guess: https://docs.python.org/3/library/asyncio-task.html#coroutine ... except that there it is referring to decorated generator functions.

That feels like a category error to me because coroutines are a generalisation a functions so if anything is the coroutine itself then it is the async def function rather than the object it returns but I guess if that's what's already being used.

I agree with this last point, and the "cofunction" terminology handled that better... In practice, I don't think this kind of thing usually causes much of a problem. For example, when first learning Swift, you have to learn that an iterator isn't really an iterator, it's a generalized index, but within the first day you've already forgotten the issue and you're just using iterators. It's no worse than switching back and forth between Self and C++, which both have things that as reasonably accurately called "iterators" but nevertheless work completely differently. But maybe the best thing to do here is look at the terminology used in the F# papers (which I think introduced the await/async idea), and then see if the same terminology is used in practice in more widespread languages like C# that borrowed the idea, and if so just go with that. Even if it's wrong, it'll be the same wrong that everyone else is learning, and if we don't have something clearly better...

...

If the issue is that there are other things that are coroutines besides the coroutine type... well, there are plenty of things that are iterators that are all of unrelated types, and has anyone ever been confused by that? (Of course people have been confused by iterator vs. iterable, but that's a different issue, and one that doesn't have a parallel here.)

There is no concrete "iterator" type. The use of iterator as a type is explicitly intended to refer to a range of different types of objects analogous to using an interface in Java.

The PEP proposes at the same time that the word coroutine should be both a generic term for objects exposing a certain interface and also the term for a specific language construct: the function resulting from an async def statement.

So if I say that something is a "coroutine" it's really not clear what that means. It could mean an an asyncio.coroutine generator function, it could mean an async def function or it could mean both. Worse it could mean the object returned by either of those types of functions.

-- Oscar _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/