Re: [Python-Dev] PEP 492: async/await in Python; v3

Greg, On 2015-04-29 6:46 PM, Greg Ewing wrote: Yury Selivanov wrote: Won't that prevent some existing generator-based coroutines (ones not decorated with @coroutine) from calling ones implemented with 'async def'? It would. But that's not a backwards compatibility issue. It seems to go ag

Re: [Python-Dev] PEP 492: async/await in Python; v3

Yury Selivanov wrote: Won't that prevent some existing generator-based coroutines (ones not decorated with @coroutine) from calling ones implemented with 'async def'? It would. But that's not a backwards compatibility issue. It seems to go against Guido's desire for the new way to be a 100%

Re: [Python-Dev] PEP 492: async/await in Python; v3

Greg, On 2015-04-29 5:12 AM, Greg Ewing wrote: Guido van Rossum wrote: On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov mailto:yselivanov...@gmail.com>> wrote: > Why StopAsyncIteration? ''' I keep wanting to propose to rename this to AsyncStopIteration. +1, that

Re: [Python-Dev] PEP 492: async/await in Python; v3

Yury Selivanov writes: > Agree. Do you think it'd be better to combine comprehensions > and async lambdas in one section? No, I'd keep them separate. For one thing, given Guido's long-standing lack of enthusiasm for lambda, they'll need to be separate PEPs. ___

Re: [Python-Dev] PEP 492: async/await in Python; v3

Greg, On 2015-04-29 5:13 AM, Greg Ewing wrote: Yury Selivanov wrote: On 2015-04-28 11:59 PM, Greg wrote: On 29/04/2015 9:49 a.m., Guido van Rossum wrote: *But* every generator-based coroutine *must* be decorated with `asyncio.coroutine()`. This is potentially a backwards incom

Re: [Python-Dev] PEP 492: async/await in Python; v3

Greg, On 2015-04-29 5:12 AM, Greg Ewing wrote: Yury Selivanov wrote: It's important to at least have 'iscoroutine' -- to check that the object is a coroutine function. A typical use-case would be a web framework that lets you to bind coroutines to specific http methods/paths: @http.get('

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 2015-04-29 5:13 AM, Greg Ewing wrote: Yury Selivanov wrote: 3. GenObject __iter__ and __next__ raise error *only* if it has CO_NATIVE_COROUTINE flag. So iter(), next(), for..in aren't supported only for 'async def' functions (but will work ok on asyncio generator-based coroutines) What

Re: [Python-Dev] PEP 492: async/await in Python; v3

Yury Selivanov wrote: 3. GenObject __iter__ and __next__ raise error *only* if it has CO_NATIVE_COROUTINE flag. So iter(), next(), for..in aren't supported only for 'async def' functions (but will work ok on asyncio generator-based coroutines) What about new 'async def' code called by existin

Re: [Python-Dev] PEP 492: async/await in Python; v3

Yury Selivanov wrote: On 2015-04-28 11:59 PM, Greg wrote: On 29/04/2015 9:49 a.m., Guido van Rossum wrote: *But* every generator-based coroutine *must* be decorated with `asyncio.coroutine()`. This is potentially a backwards incompatible change. See below. I worry about backwar

Re: [Python-Dev] PEP 492: async/await in Python; v3

Guido van Rossum wrote: On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov > wrote: > Why StopAsyncIteration? ''' I keep wanting to propose to rename this to AsyncStopIteration. +1, that seems more consistent to me too. And since

Re: [Python-Dev] PEP 492: async/await in Python; v3

Yury Selivanov wrote: I also like Guido's suggestion to use "native coroutine" term. I'll update the PEP (I have several branches of it in the repo that I need to merge before the rename). I'd still prefer to avoid use of the word "coroutine" altogether as being far too overloaded. I think eve

Re: [Python-Dev] PEP 492: async/await in Python; v3

Guido van Rossum wrote: There's a cost to __future__ imports too. The current proposal is a pretty clever hack -- and we've done similar hacks in the past There's a benefit to having a __future__ import beyond avoiding hackery: by turning on the __future__ you can find out what will break when

Re: [Python-Dev] PEP 492: async/await in Python; v3

Yury Selivanov wrote: It's important to at least have 'iscoroutine' -- to check that the object is a coroutine function. A typical use-case would be a web framework that lets you to bind coroutines to specific http methods/paths: @http.get('/spam') async def handle_spam(request):

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 04/28, Guido van Rossum wrote: > On Tue, Apr 28, 2015 at 4:55 PM, Ethan Furman wrote: >> On 04/28, Yury Selivanov wrote: >> >> >>> This limitation will go away as soon as ``async`` and ``await`` ate >> >>> proper keywords. Or if it's decided to use a future import for this >> >>> PEP. >> >> `a

Re: [Python-Dev] PEP 492: async/await in Python; v3

Guido, I found a solution how to disable 'yield from', iter()/tuple() and 'for..in' on native coroutines with 100% backwards compatibility. The idea is to add one more code object flag: CO_NATIVE_COROUTINE, which will be applied, along with CO_COROUTINE to all 'async def' functions. This way:

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 2015-04-28 11:59 PM, Greg wrote: On 29/04/2015 9:49 a.m., Guido van Rossum wrote: c) 'yield from' only accept coroutine objects from generators decorated with 'types.coroutine'. That means that existing asyncio generator-based coroutines will happily yield from both coroutin

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 29/04/2015 9:49 a.m., Guido van Rossum wrote: c) 'yield from' only accept coroutine objects from generators decorated with 'types.coroutine'. That means that existing asyncio generator-based coroutines will happily yield from both coroutines and generators. *But* every gene

Re: [Python-Dev] PEP 492: async/await in Python; v3

Hi Stephen, Thanks a lot for the feedback and suggestions. I'll apply them to the PEP. On 2015-04-28 11:03 PM, Stephen J. Turnbull wrote: Literary critic here. In section "Specification" > It is strongly suggested that the reader understands how coroutines > are implemented in Python (PEP

Re: [Python-Dev] PEP 492: async/await in Python; v3

On Tue, Apr 28, 2015 at 4:55 PM, Ethan Furman wrote: > On 04/28, Yury Selivanov wrote: > > >>> This limitation will go away as soon as ``async`` and ``await`` ate > >>> proper keywords. Or if it's decided to use a future import for this > >>> PEP. > > `async` and `await` need to be proper keywor

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 04/28, Yury Selivanov wrote: >>> This limitation will go away as soon as ``async`` and ``await`` ate >>> proper keywords. Or if it's decided to use a future import for this >>> PEP. `async` and `await` need to be proper keywords, and __future__ imports is how we do that (see, e.g., PEP 355 a

Re: [Python-Dev] PEP 492: async/await in Python; v3

Hi Guido, Thank you for a very detailed review. Comments below: On 2015-04-28 5:49 PM, Guido van Rossum wrote: Inline comments below... On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov wrote: Hi python-dev, Another round of updates. Reference implementation has been updated: https://githu

Re: [Python-Dev] PEP 492: async/await in Python; v3

Inline comments below... On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov wrote: > Hi python-dev, > > Another round of updates. Reference implementation > has been updated: https://github.com/1st1/cpython/tree/await > (includes all things from the below summary of updates + > tests). > > > Summa

Re: [Python-Dev] PEP 492: async/await in Python; v3

Ethan, On 2015-04-28 11:29 AM, Ethan Furman wrote: On 04/28, Yury Selivanov wrote: On 2015-04-28 1:43 AM, Stefan Behnel wrote: Should a Generator then inherit from both Iterator and Coroutine, or would that counter your intention to separate coroutines from generators as a concept? I mean, the

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 04/28, Yury Selivanov wrote: > On 2015-04-28 1:43 AM, Stefan Behnel wrote: >> Should a Generator then inherit from both Iterator and Coroutine, or would >> that counter your intention to separate coroutines from generators as a >> concept? I mean, they do share the same interface ... > > Them

Re: [Python-Dev] PEP 492: async/await in Python; v3

Hi Stefan, On 2015-04-28 1:43 AM, Stefan Behnel wrote: Should a Generator then inherit from both Iterator and Coroutine, or would that counter your intention to separate coroutines from generators as a concept? I mean, they do share the same interface ... Them sharing the same interface depend

Re: [Python-Dev] PEP 492: async/await in Python; v3

Hi Walter, On 2015-04-28 10:23 AM, Walter Dörwald wrote: Key properties of coroutines: * ``async def`` functions are always coroutines, even if they do not contain ``await`` expressions. * It is a ``SyntaxError`` to have ``yield`` or ``yield from`` expressions in an ``async`` function. Does

Re: [Python-Dev] PEP 492: async/await in Python; v3

On 28 Apr 2015, at 5:07, Yury Selivanov wrote: Hi python-dev, Another round of updates. Reference implementation has been updated: https://github.com/1st1/cpython/tree/await (includes all things from the below summary of updates + tests). [...] New Coroutine Declaration Syntax ---

Re: [Python-Dev] PEP 492: async/await in Python; v3

Yury Selivanov schrieb am 28.04.2015 um 05:07: > e) Should we add a coroutine ABC (for cython etc)? Sounds like the right thing to do, yes. IIUC, a Coroutine would be a new stand-alone ABC with send, throw and close methods. Should a Generator then inherit from both Iterator and Coroutine, or wou