On 1 May 2015 at 16:31, Guido van Rossum email@example.com wrote:
On Fri, May 1, 2015 at 5:50 AM, Stefan Behnel firstname.lastname@example.org wrote:
Yury Selivanov schrieb am 30.04.2015 um 03:30:
- *native coroutine* term is used for "async def" functions.
When I read "native", I think of native (binary) code. So "native coroutine" sounds like it's implemented in some compiled low-level language. That might be the case (certainly in the CPython world), but it's not related to this PEP nor its set of examples.
We should discuss how we will name new 'async def' coroutines in Python Documentation if the PEP is accepted.
Well, it doesn't hurt to avoid obvious misleading terminology upfront.
I think "obvious[ly] misleading" is too strong, nobody is trying to mislead anybody, we just have different associations with the same word. Given the feedback I'd call "native coroutine" suboptimal (even though I proposed it myself) and I am now in favor of using "async function".
But what if you have async methods? I know, a method is almost a function, but still, sounds slightly confusing.
IMHO, these are really classical coroutines. If gevent calls them coroutines, I don't think asyncio has any less right to call them coroutines.
You have to ask yourself this: a new programmer, when he sees mentions of coroutines, how likely is he to understand what he is dealing with? What about "async function"? The former is a well known concept, since decades ago, while the latter is something he probably (at least me) never heard of before.
For me, an async function is just as likely to be an API that is asynchronous in the sense that it takes an extra "callback" parameter to be called when the asynchronous work is done.
I think coroutine is the name of a concept, not a specific implementation.