On Tue, Nov 29, 2016 at 11:39 AM, Thomas Nyberg <tomuxi...@gmx.com> wrote:
> This is in reply to this message in the archives: > > https://mail.python.org/pipermail/async-sig/2016-October/000141.html > > Nathaniel Smith: > > I've found that when talking about async/await stuff recently, I've > > mostly dropped the word "coroutine" from my vocabulary and replaced it > > with "async function". I'm writing to suggest that we might want > to > > make this switch as a community, and do it now, before the next 10x > > increase in the async/await userbase. > > For what it's worth, I 100% agree. > ...yes. > > > *Accuracy*: Speaking of jargon, the term "coroutine" *is* an existing > > piece of jargon in computer science, and our term and their term don't > > quite match up. This isn't a huge deal, but it's unnecessary > > confusion. According to Wikipedia I guess technically we don't even > > have "true" coroutines, just "semicoroutines"? And every generator has > > just as much claim to being a coroutine-in-the-CS-sense as an async > > function does, but when we say coroutine we don't mean generators. > > (Except when we do.) This confusion might partly reflect the somewhat > > confusing transition from 'yield from' to async/await, as demonstrated > > by the official doc's somewhat confusing definition of "coroutine": > > I've personally been very confused lately by python's terminology. I've > always understood coroutines to have nothing a priori to do with event > loops, scheduling. For example, I've understood coroutines as being > objects that allow the following kind of flow (taken from > https://en.wikipedia.org/wiki/Coroutine#Comparison_with_subroutines): > I actually think this _is_ a bit of a big deal. Looking at things like: http://wla.berkeley.edu/~cs61a/fa11/lectures/streams.html#coroutines and (where generators were inspired from, for python) the Icon Programming Language book (e.g. co-expressions, and references to coroutines, e.g. p.119) http://www.cs.arizona.edu/icon/books.htm I think - really - async != coroutines, and (as others have said) muddies the waters, and kills some clarity. - Yarko > var q := new queue > > coroutine produce > loop > while q is not full > create some new items > add the items to q > yield to consume > > coroutine consume > loop > while q is not empty > remove some items from q > use the items > yield to produce > > Python has basically supported this flow since 2.x (apart from the > terminology issue of semi-coroutines mentioned above which I feel is > relatively minor). > > This big point though is that being scheduled or asyncronous is kind of > a separate property. Posix threads are implemented by feeding it a > routine to start things off just like much of python's asyncronous stuff > is built around coroutines, but I don't feel like the term "coroutines" > should be merged into both just as routines aren't automatically tied to > threads. > > Personally I think if anything the best possible comparison else where > in computer science are the haskell thunks which delay execution until > needed. That's the first thing I think about when I see how curio is > setup for example. > > I recognize that it is very unlikely that this will change (hey language > meaning changes over time), but I felt like I should reply after finding > this thread because I personally have been very confused by the > terminology used by python. (Personally I've been using coroutines by my > definition for years using yield/send.) > > Thanks a lot for the write-up though. You saved my sanity a little > bit... > > Cheers, > Thomas > _______________________________________________ > Async-sig mailing list > Async-sig@python.org > https://mail.python.org/mailman/listinfo/async-sig > Code of Conduct: https://www.python.org/psf/codeofconduct/ >
_______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
