<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 1, 2015 at 8:55 AM, Gustavo Carneiro <span dir="ltr"><<a href="mailto:gjcarneiro@gmail.com" target="_blank">gjcarneiro@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 1 May 2015 at 16:31, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div class="gmail_extra"><div class="gmail_quote">On Fri, May 1, 2015 at 5:50 AM, Stefan Behnel <span dir="ltr"><<a href="mailto:stefan_ml@behnel.de" target="_blank">stefan_ml@behnel.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Yury Selivanov schrieb am 30.04.2015 um 03:30:<br>
</span><span>> 1. Terminology:<br>
> - *native coroutine* term is used for "async def" functions.<br>
<br>
</span>When I read "native", I think of native (binary) code. So "native<br>
coroutine" sounds like it's implemented in some compiled low-level<br>
language. That might be the case (certainly in the CPython world), but it's<br>
not related to this PEP nor its set of examples.<br>
<span><br>
<br>
> We should discuss how we will name new 'async def' coroutines in<br>
> Python Documentation if the PEP is accepted.<br>
<br>
</span>Well, it doesn't hurt to avoid obvious misleading terminology upfront.<span></span><br></blockquote></div><br></div></span><div class="gmail_extra">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".<br clear="all"></div></div></blockquote><div><br></div></div></div><div>But what if you have async methods?  I know, a method is almost a function, but still, sounds slightly confusing.</div><div><br></div><div>IMHO, these are really classical coroutines.  If gevent calls them coroutines, I don't think asyncio has any less right to call them coroutines.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I think coroutine is the name of a concept, not a specific implementation.</div><div><br></div><div>Cheers,<br></div><br></div></div></div></blockquote><div> Cheers indeed! I agree that the *concept* is best called coroutine -- and we have used this term ever since PEP 342. But when we're talking specifics and trying to distinguish e.g. a function declared with 'async def' from a regular function or from a regular generator function, using 'async function' sounds right. And 'async method' if it's a method.<br></div></div><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>