From njs at pobox.com Sat Oct 8 20:00:21 2016 From: njs at pobox.com (Nathaniel Smith) Date: Sat, 8 Oct 2016 17:00:21 -0700 Subject: [Async-sig] A modest terminological proposal Message-ID: 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. Rationale: *Consistency*: If the only two words to keep track of were function vs coroutine, that would be one thing. But here's a list of syntax constructs we have now, and how we talk about them in English: with -> applies a *context manager* to a *with block* async with -> applies an *async context manager* to an *async with block* for -> does a *loop* over an *iterator* async for -> does an *async loop* over an *async iterator* def + yield -> makes a *generator* async def + yield -> makes an *async generator* [... for ...] -> is a *comprehension* [... async for ...] -> is an *async comprehension* def -> creates a *function* async def -> creates a *coroutine* One of these is not like the others. Why? It's a pointless toe-stub for newcomers. *Expressivity:* Once I started talking about async functions, I've found my vocabulary suddenly expanding with useful new bonus terms, like "async method" (= an async def inside a class body), or "async callable" (= any callable that returns an awaitable, emphasizing the duck type rather than the concrete type). *Approachability*: What is a "coroutine" anyway? Is it like a monad? Am I going to have to learn about endofunctors and continuations next? Of course we've all gotten used to the term now so we don't notice, but for a new user this is an obviously jargony "if you don't have a PhD then this isn't *for* you" kind of word. It's not hospitable. Plus, it emphasizes the implementor under-the-hood point of view, not the user point of view. (Which is totally understandable! Because we're just now transitioning from the internal implementors hacking things out phase to the broad general user base phase, but that's why we should fix this now.) For an end-user, especially one starting out, they don't need to know or care about all the coroutine stuff that async/await is using to make the magic happen, they can learn that later. To get started, all you need to know is that you do async stuff by using async functions and sticking an 'await' onto your I/O calls. A lot of work went into abstracting away that magic and giving it a friendly Python syntax; the English syntax should follow suit. *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": https://docs.python.org/3/library/asyncio-task.html#coroutine But going forward, yield-from-based coroutines and @asyncio.coroutine and all that are quickly becoming a historical curiosity, and most of the time what we really want to be talking about are just async functions. *So:* I'm not suggesting we modify Python itself to rename types.coroutine or the .cr_* fields or anything, that's all expert internal stuff (possible exception: the __repr__ for async functions). But I do propose that we all agree to do a search/replace for s/coroutine/async function/g on our end-user docs and when generally talking about these things, and announce that we're doing so. It's a small thing and a bit of work, but if there's a general agreement to do it in a coordinated way then I think it could be pretty straightforward transition that will pay dividends for a long time. -n -- Nathaniel J. Smith -- https://vorpus.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Sat Oct 8 22:48:34 2016 From: guido at python.org (Guido van Rossum) Date: Sat, 8 Oct 2016 19:48:34 -0700 Subject: [Async-sig] A modest terminological proposal In-Reply-To: References: Message-ID: I've heard people call it an "async def" too. I don't think it's quite as dramatic as you worry about. People also talk about generators (not generator functions) and even though there's a further ambiguity between the function and the type of object it returns, we still get along. There's also the @coroutine decorator. If you have a specific piece of documentation in mind, let's talk -- maybe it's fine to change. On Sat, Oct 8, 2016 at 5:00 PM, Nathaniel Smith wrote: > 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. Rationale: > > Consistency: If the only two words to keep track of were function vs > coroutine, that would be one thing. But here's a list of syntax constructs > we have now, and how we talk about them in English: > > with -> applies a context manager to a with block > async with -> applies an async context manager to an async with block > > for -> does a loop over an iterator > async for -> does an async loop over an async iterator > > def + yield -> makes a generator > async def + yield -> makes an async generator > > [... for ...] -> is a comprehension > [... async for ...] -> is an async comprehension > > def -> creates a function > async def -> creates a coroutine > > One of these is not like the others. Why? It's a pointless toe-stub for > newcomers. > > Expressivity: Once I started talking about async functions, I've found my > vocabulary suddenly expanding with useful new bonus terms, like "async > method" (= an async def inside a class body), or "async callable" (= any > callable that returns an awaitable, emphasizing the duck type rather than > the concrete type). > > Approachability: What is a "coroutine" anyway? Is it like a monad? Am I > going to have to learn about endofunctors and continuations next? Of course > we've all gotten used to the term now so we don't notice, but for a new user > this is an obviously jargony "if you don't have a PhD then this isn't *for* > you" kind of word. It's not hospitable. > > Plus, it emphasizes the implementor under-the-hood point of view, not the > user point of view. (Which is totally understandable! Because we're just now > transitioning from the internal implementors hacking things out phase to the > broad general user base phase, but that's why we should fix this now.) For > an end-user, especially one starting out, they don't need to know or care > about all the coroutine stuff that async/await is using to make the magic > happen, they can learn that later. To get started, all you need to know is > that you do async stuff by using async functions and sticking an 'await' > onto your I/O calls. A lot of work went into abstracting away that magic and > giving it a friendly Python syntax; the English syntax should follow suit. > > 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": > > https://docs.python.org/3/library/asyncio-task.html#coroutine > > But going forward, yield-from-based coroutines and @asyncio.coroutine and > all that are quickly becoming a historical curiosity, and most of the time > what we really want to be talking about are just async functions. > > So: I'm not suggesting we modify Python itself to rename types.coroutine or > the .cr_* fields or anything, that's all expert internal stuff (possible > exception: the __repr__ for async functions). But I do propose that we all > agree to do a search/replace for s/coroutine/async function/g on our > end-user docs and when generally talking about these things, and announce > that we're doing so. It's a small thing and a bit of work, but if there's a > general agreement to do it in a coordinated way then I think it could be > pretty straightforward transition that will pay dividends for a long time. > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > > _______________________________________________ > Async-sig mailing list > Async-sig at python.org > https://mail.python.org/mailman/listinfo/async-sig > Code of Conduct: https://www.python.org/psf/codeofconduct/ -- --Guido van Rossum (python.org/~guido) From njs at pobox.com Sat Oct 8 23:50:18 2016 From: njs at pobox.com (Nathaniel Smith) Date: Sat, 8 Oct 2016 20:50:18 -0700 Subject: [Async-sig] A modest terminological proposal In-Reply-To: References: Message-ID: On Sat, Oct 8, 2016 at 7:48 PM, Guido van Rossum wrote: > I've heard people call it an "async def" too. > > I don't think it's quite as dramatic as you worry about. People also > talk about generators (not generator functions) and even though > there's a further ambiguity between the function and the type of > object it returns, we still get along. Hmm, I don't mean to be dramatic. Obviously the world will not end if we keep using "coroutine" as the standard term :-). I just think that calling them "async functions" (and "async function objects" when the distinction is important) would be a nice unambiguous win for pedagogy and clarity, and that it's worth grabbing those when you get the chance. "coroutine" says more about the history of how we got here than about what these things actually mean to a regular end-user; "async function" is so transparent that you can skip the vocab discussion and go straight to talking about how to use them. > There's also the @coroutine decorator. There's two of them, even: @types.coroutine and @asyncio.coroutine. I'm not really sure what the difference is -- I think at this point we could delete some code by making the latter an alias for the former? But for now they're still independent and I might be missing something. And unless I am missing something, these are only useful in rather unusual situations: either because you're trying to maintain compatibility with 3.4 (which I think will rapidly become irrelevant for most asyncio users, if it isn't already) or you're implementing your own trampoline (e.g. [1][2]). So even if we leave the decorators alone, it doesn't really stop us from switching to clearer terminology for day-to-day usage -- most people will never encounter @coroutine anyway. (For completeness: the other stdlib identifiers I see that mention "coroutine" are: sys.{get,set}_coroutine_wrapper, several functions in inspect, and asyncio.run_coroutine_threadsafe.) > If you have a specific piece of documentation in mind, let's talk -- > maybe it's fine to change. Well, it's a basic concept that gets mentioned constantly throughout all discussions... For example, I count 29 instances in [3] and 53 instances in [4]. Clearly it's useful to have a standard term for these things. -n [1] https://github.com/dabeaz/curio/blob/6166a54a731df59c15fe27791d1c6b048f09f941/curio/traps.py#L46 [2] https://github.com/njsmith/async_generator/blob/fab4af987cb86c6db549131b66d3ab4c4e327a29/async_generator/impl.py#L13 [3] https://docs.python.org/3/library/asyncio-stream.html [4] https://curio.readthedocs.io/en/latest/reference.html -- Nathaniel J. Smith -- https://vorpus.org From guido at python.org Sat Oct 8 23:59:54 2016 From: guido at python.org (Guido van Rossum) Date: Sat, 8 Oct 2016 20:59:54 -0700 Subject: [Async-sig] A modest terminological proposal In-Reply-To: References: Message-ID: I'd like input from others, but maybe it's worth expanding the scope to python-ideas? Not too many people read async-sig. (Or should that be coroutine-sig? :-) On Sat, Oct 8, 2016 at 8:50 PM, Nathaniel Smith wrote: > On Sat, Oct 8, 2016 at 7:48 PM, Guido van Rossum wrote: >> I've heard people call it an "async def" too. >> >> I don't think it's quite as dramatic as you worry about. People also >> talk about generators (not generator functions) and even though >> there's a further ambiguity between the function and the type of >> object it returns, we still get along. > > Hmm, I don't mean to be dramatic. Obviously the world will not end if > we keep using "coroutine" as the standard term :-). I just think that > calling them "async functions" (and "async function objects" when the > distinction is important) would be a nice unambiguous win for pedagogy > and clarity, and that it's worth grabbing those when you get the > chance. "coroutine" says more about the history of how we got here > than about what these things actually mean to a regular end-user; > "async function" is so transparent that you can skip the vocab > discussion and go straight to talking about how to use them. > >> There's also the @coroutine decorator. > > There's two of them, even: @types.coroutine and @asyncio.coroutine. > I'm not really sure what the difference is -- I think at this point we > could delete some code by making the latter an alias for the former? > But for now they're still independent and I might be missing > something. > > And unless I am missing something, these are only useful in rather > unusual situations: either because you're trying to maintain > compatibility with 3.4 (which I think will rapidly become irrelevant > for most asyncio users, if it isn't already) or you're implementing > your own trampoline (e.g. [1][2]). So even if we leave the decorators > alone, it doesn't really stop us from switching to clearer terminology > for day-to-day usage -- most people will never encounter @coroutine > anyway. > > (For completeness: the other stdlib identifiers I see that mention > "coroutine" are: sys.{get,set}_coroutine_wrapper, several functions in > inspect, and asyncio.run_coroutine_threadsafe.) > >> If you have a specific piece of documentation in mind, let's talk -- >> maybe it's fine to change. > > Well, it's a basic concept that gets mentioned constantly throughout > all discussions... For example, I count 29 instances in [3] and 53 > instances in [4]. Clearly it's useful to have a standard term for > these things. > > -n > > [1] https://github.com/dabeaz/curio/blob/6166a54a731df59c15fe27791d1c6b048f09f941/curio/traps.py#L46 > [2] https://github.com/njsmith/async_generator/blob/fab4af987cb86c6db549131b66d3ab4c4e327a29/async_generator/impl.py#L13 > [3] https://docs.python.org/3/library/asyncio-stream.html > [4] https://curio.readthedocs.io/en/latest/reference.html > > -- > Nathaniel J. Smith -- https://vorpus.org -- --Guido van Rossum (python.org/~guido) From hawkowl at atleastfornow.net Sun Oct 9 00:10:19 2016 From: hawkowl at atleastfornow.net (Amber "Hawkie" Brown) Date: Sun, 9 Oct 2016 15:10:19 +1100 Subject: [Async-sig] A modest terminological proposal In-Reply-To: References: Message-ID: <769FF712-485A-4A43-9E1B-1BEE0966071A@atleastfornow.net> > On 9 Oct. 2016, at 14:50, Nathaniel Smith wrote: > > On Sat, Oct 8, 2016 at 7:48 PM, Guido van Rossum wrote: >> I've heard people call it an "async def" too. >> >> I don't think it's quite as dramatic as you worry about. People also >> talk about generators (not generator functions) and even though >> there's a further ambiguity between the function and the type of >> object it returns, we still get along. > > Hmm, I don't mean to be dramatic. Obviously the world will not end if > we keep using "coroutine" as the standard term :-). I just think that > calling them "async functions" (and "async function objects" when the > distinction is important) would be a nice unambiguous win for pedagogy > and clarity, and that it's worth grabbing those when you get the > chance. "coroutine" says more about the history of how we got here > than about what these things actually mean to a regular end-user; > "async function" is so transparent that you can skip the vocab > discussion and go straight to talking about how to use them. I am of the reverse opinion -- they should be called coroutines, not asynchronous functions. Calling them "async functions" implies that they are asynchronous; they are actually completely synchronous constructs built of potentially asynchronous code and used in larger asynchronous systems. A coroutine, by itself, is not asynchronous. But I guess it's 'async def' and not 'coro def'... :) As an example of the consequences of naming, there have been several cases where asyncio users of Autobahn have attempted to do large file I/O, and thought that because they were using 'asyncio' it would be fine, and have ended up blocking the event loop because of it. There's no such thing as asynchronous file system access, which is one of the most basic kinds of I/O, which has lead to this impression. - Amber From njs at pobox.com Sun Oct 9 01:25:59 2016 From: njs at pobox.com (Nathaniel Smith) Date: Sat, 8 Oct 2016 22:25:59 -0700 Subject: [Async-sig] A modest terminological proposal In-Reply-To: <769FF712-485A-4A43-9E1B-1BEE0966071A@atleastfornow.net> References: <769FF712-485A-4A43-9E1B-1BEE0966071A@atleastfornow.net> Message-ID: On Sat, Oct 8, 2016 at 9:10 PM, Amber "Hawkie" Brown wrote: > >> On 9 Oct. 2016, at 14:50, Nathaniel Smith wrote: >> >> On Sat, Oct 8, 2016 at 7:48 PM, Guido van Rossum wrote: >>> I've heard people call it an "async def" too. >>> >>> I don't think it's quite as dramatic as you worry about. People also >>> talk about generators (not generator functions) and even though >>> there's a further ambiguity between the function and the type of >>> object it returns, we still get along. >> >> Hmm, I don't mean to be dramatic. Obviously the world will not end if >> we keep using "coroutine" as the standard term :-). I just think that >> calling them "async functions" (and "async function objects" when the >> distinction is important) would be a nice unambiguous win for pedagogy >> and clarity, and that it's worth grabbing those when you get the >> chance. "coroutine" says more about the history of how we got here >> than about what these things actually mean to a regular end-user; >> "async function" is so transparent that you can skip the vocab >> discussion and go straight to talking about how to use them. > > I am of the reverse opinion -- they should be called coroutines, not asynchronous functions. Small but meaningful nitpick: the proposal is to call them "async functions", not "asynchronous functions". It's named after the "async" keyword. Any resemblance of that keyword to an English word is ... a separate problem :-). > Calling them "async functions" implies that they are asynchronous; they are actually completely synchronous constructs built of potentially asynchronous code and used in larger asynchronous systems. A coroutine, by itself, is not asynchronous. But I guess it's 'async def' and not 'coro def'... :) > > As an example of the consequences of naming, there have been several cases where asyncio users of Autobahn have attempted to do large file I/O, and thought that because they were using 'asyncio' it would be fine, and have ended up blocking the event loop because of it. There's no such thing as asynchronous file system access, which is one of the most basic kinds of I/O, which has lead to this impression. Oh yeah, communicating this is definitely a huge challenge. But I feel like as long as the keyword is 'async' and the words "async" or "asynchronous" are on the book covers and the for loops and generally attached to every single thing except for the documentation-term-for-the-function-like-thingummies, then this confusion is going to happen and we're going to have to do the work to explain what we mean when we say 'async'. Throwing in "coroutine" as an extra piece of opaque jargon doesn't really help this, IMO. And if we have to explain what 'async' means anyway, then 'async function' comes along for free. (Of course if teaching someone about this stuff I still have the *option* of explaining what coroutines are and how async functions are an example of the concept, if I think that well help -- just now it's my decision whether I want to go there or not :-).) -n -- Nathaniel J. Smith -- https://vorpus.org From njs at pobox.com Sun Oct 9 01:28:28 2016 From: njs at pobox.com (Nathaniel Smith) Date: Sat, 8 Oct 2016 22:28:28 -0700 Subject: [Async-sig] A modest terminological proposal In-Reply-To: References: Message-ID: I figured I'd throw it out here for initial feedback on the theory that it'd be higher signal to noise, and then proceed to python-ideas if the async aficionados seemed generally in favor. On Sat, Oct 8, 2016 at 8:59 PM, Guido van Rossum wrote: > I'd like input from others, but maybe it's worth expanding the scope > to python-ideas? Not too many people read async-sig. (Or should that > be coroutine-sig? :-) > > On Sat, Oct 8, 2016 at 8:50 PM, Nathaniel Smith wrote: >> On Sat, Oct 8, 2016 at 7:48 PM, Guido van Rossum wrote: >>> I've heard people call it an "async def" too. >>> >>> I don't think it's quite as dramatic as you worry about. People also >>> talk about generators (not generator functions) and even though >>> there's a further ambiguity between the function and the type of >>> object it returns, we still get along. >> >> Hmm, I don't mean to be dramatic. Obviously the world will not end if >> we keep using "coroutine" as the standard term :-). I just think that >> calling them "async functions" (and "async function objects" when the >> distinction is important) would be a nice unambiguous win for pedagogy >> and clarity, and that it's worth grabbing those when you get the >> chance. "coroutine" says more about the history of how we got here >> than about what these things actually mean to a regular end-user; >> "async function" is so transparent that you can skip the vocab >> discussion and go straight to talking about how to use them. >> >>> There's also the @coroutine decorator. >> >> There's two of them, even: @types.coroutine and @asyncio.coroutine. >> I'm not really sure what the difference is -- I think at this point we >> could delete some code by making the latter an alias for the former? >> But for now they're still independent and I might be missing >> something. >> >> And unless I am missing something, these are only useful in rather >> unusual situations: either because you're trying to maintain >> compatibility with 3.4 (which I think will rapidly become irrelevant >> for most asyncio users, if it isn't already) or you're implementing >> your own trampoline (e.g. [1][2]). So even if we leave the decorators >> alone, it doesn't really stop us from switching to clearer terminology >> for day-to-day usage -- most people will never encounter @coroutine >> anyway. >> >> (For completeness: the other stdlib identifiers I see that mention >> "coroutine" are: sys.{get,set}_coroutine_wrapper, several functions in >> inspect, and asyncio.run_coroutine_threadsafe.) >> >>> If you have a specific piece of documentation in mind, let's talk -- >>> maybe it's fine to change. >> >> Well, it's a basic concept that gets mentioned constantly throughout >> all discussions... For example, I count 29 instances in [3] and 53 >> instances in [4]. Clearly it's useful to have a standard term for >> these things. >> >> -n >> >> [1] https://github.com/dabeaz/curio/blob/6166a54a731df59c15fe27791d1c6b048f09f941/curio/traps.py#L46 >> [2] https://github.com/njsmith/async_generator/blob/fab4af987cb86c6db549131b66d3ab4c4e327a29/async_generator/impl.py#L13 >> [3] https://docs.python.org/3/library/asyncio-stream.html >> [4] https://curio.readthedocs.io/en/latest/reference.html >> >> -- >> Nathaniel J. Smith -- https://vorpus.org > > > > -- > --Guido van Rossum (python.org/~guido) -- Nathaniel J. Smith -- https://vorpus.org From ben at bendarnell.com Sun Oct 9 03:34:55 2016 From: ben at bendarnell.com (Ben Darnell) Date: Sun, 09 Oct 2016 07:34:55 +0000 Subject: [Async-sig] A modest terminological proposal In-Reply-To: References: Message-ID: I generally like the idea of calling the result of `async def` an "async function", and replacing most uses of "coroutine" in the docs with "async function". The potential confusion with "asynchronous function" (which in my taxonomy is a broader category including both coroutines and functions that take callbacks) is unfortunate, but as long as the syntax is `async def` the term "async function" is almost inevitable and we might as well embrace it. In Tornado, though, I'm going to keep using the term "coroutine" because our `yield`-based decorated coroutines are important for as long as Python 2 is around. -Ben On Sun, Oct 9, 2016 at 12:00 PM Guido van Rossum wrote: > I'd like input from others, but maybe it's worth expanding the scope > > to python-ideas? Not too many people read async-sig. (Or should that > > be coroutine-sig? :-) > > > > On Sat, Oct 8, 2016 at 8:50 PM, Nathaniel Smith wrote: > > > On Sat, Oct 8, 2016 at 7:48 PM, Guido van Rossum > wrote: > > >> I've heard people call it an "async def" too. > > >> > > >> I don't think it's quite as dramatic as you worry about. People also > > >> talk about generators (not generator functions) and even though > > >> there's a further ambiguity between the function and the type of > > >> object it returns, we still get along. > > > > > > Hmm, I don't mean to be dramatic. Obviously the world will not end if > > > we keep using "coroutine" as the standard term :-). I just think that > > > calling them "async functions" (and "async function objects" when the > > > distinction is important) would be a nice unambiguous win for pedagogy > > > and clarity, and that it's worth grabbing those when you get the > > > chance. "coroutine" says more about the history of how we got here > > > than about what these things actually mean to a regular end-user; > > > "async function" is so transparent that you can skip the vocab > > > discussion and go straight to talking about how to use them. > > > > > >> There's also the @coroutine decorator. > > > > > > There's two of them, even: @types.coroutine and @asyncio.coroutine. > > > I'm not really sure what the difference is -- I think at this point we > > > could delete some code by making the latter an alias for the former? > > > But for now they're still independent and I might be missing > > > something. > > > > > > And unless I am missing something, these are only useful in rather > > > unusual situations: either because you're trying to maintain > > > compatibility with 3.4 (which I think will rapidly become irrelevant > > > for most asyncio users, if it isn't already) or you're implementing > > > your own trampoline (e.g. [1][2]). So even if we leave the decorators > > > alone, it doesn't really stop us from switching to clearer terminology > > > for day-to-day usage -- most people will never encounter @coroutine > > > anyway. > > > > > > (For completeness: the other stdlib identifiers I see that mention > > > "coroutine" are: sys.{get,set}_coroutine_wrapper, several functions in > > > inspect, and asyncio.run_coroutine_threadsafe.) > > > > > >> If you have a specific piece of documentation in mind, let's talk -- > > >> maybe it's fine to change. > > > > > > Well, it's a basic concept that gets mentioned constantly throughout > > > all discussions... For example, I count 29 instances in [3] and 53 > > > instances in [4]. Clearly it's useful to have a standard term for > > > these things. > > > > > > -n > > > > > > [1] > https://github.com/dabeaz/curio/blob/6166a54a731df59c15fe27791d1c6b048f09f941/curio/traps.py#L46 > > > [2] > https://github.com/njsmith/async_generator/blob/fab4af987cb86c6db549131b66d3ab4c4e327a29/async_generator/impl.py#L13 > > > [3] https://docs.python.org/3/library/asyncio-stream.html > > > [4] https://curio.readthedocs.io/en/latest/reference.html > > > > > > -- > > > Nathaniel J. Smith -- https://vorpus.org > > > > > > > > -- > > --Guido van Rossum (python.org/~guido) > > _______________________________________________ > > Async-sig mailing list > > Async-sig at python.org > > https://mail.python.org/mailman/listinfo/async-sig > > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Sun Oct 9 12:50:18 2016 From: guido at python.org (Guido van Rossum) Date: Sun, 9 Oct 2016 09:50:18 -0700 Subject: [Async-sig] A modest terminological proposal In-Reply-To: References: Message-ID: I think I'm convinced by Amber's argument. Coroutines are something you can look up in e.g. Knuth (or Wikipedia) and you'll find something a pretty good match. All queries for "async functions" seem to go to some ECMAScript proposal (similar in nature to PEP 492 actually) and I am not particularly eager to throw ourselves in front of that bandwagon. On Sun, Oct 9, 2016 at 12:34 AM, Ben Darnell wrote: > I generally like the idea of calling the result of `async def` an "async > function", and replacing most uses of "coroutine" in the docs with "async > function". The potential confusion with "asynchronous function" (which in my > taxonomy is a broader category including both coroutines and functions that > take callbacks) is unfortunate, but as long as the syntax is `async def` the > term "async function" is almost inevitable and we might as well embrace it. > > In Tornado, though, I'm going to keep using the term "coroutine" because our > `yield`-based decorated coroutines are important for as long as Python 2 is > around. > > -Ben > > On Sun, Oct 9, 2016 at 12:00 PM Guido van Rossum wrote: >> >> I'd like input from others, but maybe it's worth expanding the scope >> >> to python-ideas? Not too many people read async-sig. (Or should that >> >> be coroutine-sig? :-) >> >> >> >> On Sat, Oct 8, 2016 at 8:50 PM, Nathaniel Smith wrote: >> >> > On Sat, Oct 8, 2016 at 7:48 PM, Guido van Rossum >> > wrote: >> >> >> I've heard people call it an "async def" too. >> >> >> >> >> >> I don't think it's quite as dramatic as you worry about. People also >> >> >> talk about generators (not generator functions) and even though >> >> >> there's a further ambiguity between the function and the type of >> >> >> object it returns, we still get along. >> >> > >> >> > Hmm, I don't mean to be dramatic. Obviously the world will not end if >> >> > we keep using "coroutine" as the standard term :-). I just think that >> >> > calling them "async functions" (and "async function objects" when the >> >> > distinction is important) would be a nice unambiguous win for pedagogy >> >> > and clarity, and that it's worth grabbing those when you get the >> >> > chance. "coroutine" says more about the history of how we got here >> >> > than about what these things actually mean to a regular end-user; >> >> > "async function" is so transparent that you can skip the vocab >> >> > discussion and go straight to talking about how to use them. >> >> > >> >> >> There's also the @coroutine decorator. >> >> > >> >> > There's two of them, even: @types.coroutine and @asyncio.coroutine. >> >> > I'm not really sure what the difference is -- I think at this point we >> >> > could delete some code by making the latter an alias for the former? >> >> > But for now they're still independent and I might be missing >> >> > something. >> >> > >> >> > And unless I am missing something, these are only useful in rather >> >> > unusual situations: either because you're trying to maintain >> >> > compatibility with 3.4 (which I think will rapidly become irrelevant >> >> > for most asyncio users, if it isn't already) or you're implementing >> >> > your own trampoline (e.g. [1][2]). So even if we leave the decorators >> >> > alone, it doesn't really stop us from switching to clearer terminology >> >> > for day-to-day usage -- most people will never encounter @coroutine >> >> > anyway. >> >> > >> >> > (For completeness: the other stdlib identifiers I see that mention >> >> > "coroutine" are: sys.{get,set}_coroutine_wrapper, several functions in >> >> > inspect, and asyncio.run_coroutine_threadsafe.) >> >> > >> >> >> If you have a specific piece of documentation in mind, let's talk -- >> >> >> maybe it's fine to change. >> >> > >> >> > Well, it's a basic concept that gets mentioned constantly throughout >> >> > all discussions... For example, I count 29 instances in [3] and 53 >> >> > instances in [4]. Clearly it's useful to have a standard term for >> >> > these things. >> >> > >> >> > -n >> >> > >> >> > [1] >> > https://github.com/dabeaz/curio/blob/6166a54a731df59c15fe27791d1c6b048f09f941/curio/traps.py#L46 >> >> > [2] >> > https://github.com/njsmith/async_generator/blob/fab4af987cb86c6db549131b66d3ab4c4e327a29/async_generator/impl.py#L13 >> >> > [3] https://docs.python.org/3/library/asyncio-stream.html >> >> > [4] https://curio.readthedocs.io/en/latest/reference.html >> >> > >> >> > -- >> >> > Nathaniel J. Smith -- https://vorpus.org >> >> >> >> >> >> >> >> -- >> >> --Guido van Rossum (python.org/~guido) >> >> _______________________________________________ >> >> Async-sig mailing list >> >> Async-sig at python.org >> >> https://mail.python.org/mailman/listinfo/async-sig >> >> Code of Conduct: https://www.python.org/psf/codeofconduct/ >> > -- --Guido van Rossum (python.org/~guido) From njs at pobox.com Tue Oct 11 23:23:53 2016 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 11 Oct 2016 20:23:53 -0700 Subject: [Async-sig] A modest terminological proposal In-Reply-To: References: Message-ID: On Sun, Oct 9, 2016 at 9:50 AM, Guido van Rossum wrote: > I think I'm convinced by Amber's argument. Coroutines are something > you can look up in e.g. Knuth (or Wikipedia) and you'll find something > a pretty good match. All queries for "async functions" seem to go to > some ECMAScript proposal (similar in nature to PEP 492 actually) You got me curious and I did some reading... it looks like this proposal has been finalized and is starting to ship in browsers now, and that it's *very* similar to PEP 492. As in, the working group was explicitly studying "Python and C#" [1] for implementation experience, and from the user point of view the final syntax and semantics are essentially identical to our async functions / coroutines [2]. They even have Yury's async-toggles-the-keyword-status-of-await lexer hack :-). I guess personally I like it when different languages that have the same concept use the same name for it? Knuth will get you into the right ballpark, but between Python and Javascript's async functions, it looks like knowing how to use one is ~100% directly transferable to knowing how to use the other. (Apparently C# went with "async method" for their terminology, so they're consistent too.) > and I > am not particularly eager to throw ourselves in front of that > bandwagon. I vote that we think of this as them throwing themselves in front of your bandwagon ;-). -n [1] e.g. https://github.com/tc39/ecmascript-asyncawait/issues/89#issuecomment-185086819 [2] There is one interesting difference: since they already have an event loop + future implementation baked into their runtime, they elected not to separate out the coroutine trampoline as a user-replaceable library component, like Python did. Instead, their 'await foo' is effectively hard-coded to do 'foo.add_done_callback(current continuation) + suspend'. Which is identical to what the standard asyncio.Task trampoline does anyway, so this is not a difference that matters to anyone who isn't writing their own I/O library. Though I guess it means we won't be seeing a curio.js anytime soon. -- Nathaniel J. Smith -- https://vorpus.org From songofacandy at gmail.com Thu Oct 13 01:37:38 2016 From: songofacandy at gmail.com (INADA Naoki) Date: Thu, 13 Oct 2016 14:37:38 +0900 Subject: [Async-sig] [python-tulip] Python 3.6b2 will have C implemented Future In-Reply-To: References: <408d5393-82e4-4176-8d37-5c3d086c4087@googlegroups.com> Message-ID: Thanks, Ben. Both are very helpful information! On Thu, Oct 13, 2016 at 2:25 PM, Ben Darnell wrote: > [+async-sig at python.org, which is the new home for these kinds of > discussions] > > Tornado's tests are now failing on nightly with "TypeError: can't send > non-None value to a FutureIter": > https://travis-ci.org/tornadoweb/tornado/jobs/167252979 > > -Ben > > On Tue, Oct 11, 2016 at 3:55 PM INADA Naoki wrote: >> >> > If you have asyncio based project, and it uses Travis-CI, >> >> > please add "nightly" to your .travis.cnf [2]. >> >> > >> >> > [2] >> >> > >> > https://docs.travis-ci.com/user/languages/python/#Choosing-Python-versions-to-test-against >> >> >> >> Travis changed the "nightly" version to 3.7 >> >> Now "3.6-dev" is for Python 3.6beta (Still 3.6b1, it may be upgraded >> soon). >> >> >> >> -- >> >> INADA Naoki >> > -- INADA Naoki From ben at bendarnell.com Thu Oct 13 01:25:20 2016 From: ben at bendarnell.com (Ben Darnell) Date: Thu, 13 Oct 2016 05:25:20 +0000 Subject: [Async-sig] [python-tulip] Python 3.6b2 will have C implemented Future In-Reply-To: References: <408d5393-82e4-4176-8d37-5c3d086c4087@googlegroups.com> Message-ID: [+async-sig at python.org , which is the new home for these kinds of discussions] Tornado's tests are now failing on nightly with "TypeError: can't send non-None value to a FutureIter": https://travis-ci.org/tornadoweb/tornado/jobs/167252979 -Ben On Tue, Oct 11, 2016 at 3:55 PM INADA Naoki wrote: > > If you have asyncio based project, and it uses Travis-CI, > > > please add "nightly" to your .travis.cnf [2]. > > > > > > [2] > > > > https://docs.travis-ci.com/user/languages/python/#Choosing-Python-versions-to-test-against > > > > Travis changed the "nightly" version to 3.7 > > Now "3.6-dev" is for Python 3.6beta (Still 3.6b1, it may be upgraded soon). > > > > -- > > INADA Naoki > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmludo at gmail.com Fri Oct 14 11:12:38 2016 From: gmludo at gmail.com (Ludovic Gasc) Date: Fri, 14 Oct 2016 17:12:38 +0200 Subject: [Async-sig] Status of asyncio.readthedocs.io ? Message-ID: Hi everybody, For me, http://asyncio.readthedocs.io/ is enough stable now to promote the project. Ok for everybody, or you want to add content or change the structure ? BTW, thanks to all contributors, especially Victor Stinner and Mike M?ller from Python-Academy: https://github.com/asyncio-doc/asyncio-doc/graphs/contributors Have a nice week. PS: No answer before Sunday = approved by people in the mailing-lists ;-) -- Ludovic Gasc (GMLudo) http://www.gmludo.eu/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From songofacandy at gmail.com Fri Oct 14 14:47:16 2016 From: songofacandy at gmail.com (INADA Naoki) Date: Sat, 15 Oct 2016 03:47:16 +0900 Subject: [Async-sig] [python-tulip] Python 3.6b2 will have C implemented Future In-Reply-To: References: <408d5393-82e4-4176-8d37-5c3d086c4087@googlegroups.com> Message-ID: Thank you for information. I'll look it, hopefully in next week. 2016/10/15 ??2:24 "Julien Duponchelle" : > On Sun, Oct 9, 2016 at 8:06 AM Naoki INADA wrote: > >> Hi. >> >> I've just pushed C implementation of asyncio.Future [1]. >> It will be included in Python 3.6b2. >> >> It may have rough edge. But I hope it will be battle tested >> before Python 3.6.0. >> Please help us by running your tests on Python 3.6b2, and >> report issues you found. >> If you have asyncio based project, and it uses Travis-CI, >> please add "nightly" to your .travis.cnf [2]. >> >> Feedback about performance difference is also welcome. >> >> Thanks, >> >> [1]: https://hg.python.org/cpython/rev/678424183b38 >> [2] https://docs.travis-ci.com/user/languages/python/# >> Choosing-Python-versions-to-test-against >> > > Hi, > > I have setup a 3.6 build on Travis of our project GNS3 and it seem to fail. > https://travis-ci.org/GNS3/gns3-server/builds/167703118 > > To be honest I didn't dig the issue and could be wrong usage of asyncio > (or ugly mock in tests). But this could perhaps interest you. > > I think the most interresting test is: > https://travis-ci.org/GNS3/gns3-server/jobs/167702085#L2270 > > Because we test a websocket client server connection. > > Thanks a lot for your work > -------------- next part -------------- An HTML attachment was scrubbed... URL: From multisosnooley at gmail.com Mon Oct 24 13:08:08 2016 From: multisosnooley at gmail.com (MultiSosnooley .) Date: Mon, 24 Oct 2016 20:08:08 +0300 Subject: [Async-sig] sans io implementation Message-ID: Hi. I'm trying to make sans-io library. 1. Protocol works over http, so I've just passing Request object with method, url, data, etc. fields to user and receive Response object (json in this case). 2. I'm using generators for simplification of holding state of multirequest actions. Something like this: def login(): response = yield Request(...) # check server state # update state with response response = yield Request(...) # actually login yield None def act(generator): response = None while True: request = generator.send(response) if request is None: return response response = # do io act(login()) This solve problem multistep actions. The downside is that all your protocol functions, event if they have only one request and don't need response at all, must be generators. Is it ok to send just abstract Request and receive abstract Response (not just bytes)? Is there a better solution for multirequest actions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gronholm at nextday.fi Tue Oct 25 11:33:46 2016 From: alex.gronholm at nextday.fi (=?UTF-8?Q?Alex_Gr=c3=b6nholm?=) Date: Tue, 25 Oct 2016 18:33:46 +0300 Subject: [Async-sig] sans io implementation In-Reply-To: References: Message-ID: I personally recommend against using generators in any form in a sans-io protocol implementation. Are you absolutely sure that you need them? Do you understand what the responsibilities of a sans-io protocol are? 24.10.2016, 20:08, MultiSosnooley . kirjoitti: > Hi. > > I'm trying to make sans-io library. > > 1. Protocol works over http, so I've just passing Request object with > method, url, data, etc. fields to user and receive Response object > (json in this case). > 2. I'm using generators for simplification of holding state of > multirequest actions. Something like this: > > def login(): > > response = yield Request(...) # check server state > # update state with response > response = yield Request(...) # actually login > yield None > > def act(generator): > response = None > while True: > request = generator.send(response) > if request is None: > return response > response = # do io > > act(login()) > > This solve problem multistep actions. The downside is that all your > protocol functions, event if they have only one request and don't need > response at all, must be generators. > > Is it ok to send just abstract Request and receive abstract Response > (not just bytes)? > Is there a better solution for multirequest actions? > > > _______________________________________________ > Async-sig mailing list > Async-sig at python.org > https://mail.python.org/mailman/listinfo/async-sig > Code of Conduct: https://www.python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: