Hello,
I've just posted a new PEP about adding async/await to python-ideas.
Maybe I should have posted it here instead..
Anyways, please take a look.
Thanks,
Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listin
Hi Martin,
On 2015-04-21 4:23 AM, Martin Teichmann wrote:
Hi Yury, Hi List,
I do certainly like the idea of PEP 492, just some small comments:
Thank you!
why do we need two keywords? To me it is not necessarily intuitive
when to use async and when to use await (why is it async for and not
a
But I can't imagine
why would someone do that, and even if they did --
it's probably a bug or wrong usage of asyncio.
That's it! I'd be happy to hear some feedback!
Thanks,
Yury
PEP: 492
Title: Coroutines with async and await syntax
Version: $Revision$
Last-Modifie
Hi Damien,
Thanks for noticing! I pushed a fix to the peps repo.
Thanks,
Yury
On 2015-04-21 5:20 PM, Damien George wrote:
Hi Yury,
In your PEP 492 draft, in the Grammar section, I think you're missing
the modifications to the "flow_stmt" line.
Cheers,
Damien.
___
Hi Greg,
On 2015-04-22 2:05 AM, Greg Ewing wrote:
Yury Selivanov wrote:
1. CO_ASYNC flag was renamed to CO_COROUTINE;
2. sys.set_async_wrapper() was renamed to
sys.set_coroutine_wrapper();
3. New function: sys.get_coroutine_wrapper();
4. types.async_def() renamed to types.coroutine
Hi Guido,
On 2015-04-22 11:50 AM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 8:40 AM, Yury Selivanov
wrote:
On the one hand I like your idea to disallow calling
coroutines without a special keyword (await in case of
PEP 492). It has downsides, but there is some
elegance in it. On the
Hi Rajiv,
On 2015-04-22 12:53 PM, Rajiv Kumar wrote:
I'd like to suggest another way around some of the issues here, with
apologies if this has already been discussed sometime in the past.
From the viewpoint of a Python programmer, there are two distinct reasons
for wanting to suspend executio
Andrew,
On 2015-04-22 2:32 PM, Andrew Svetlov wrote:
For now I can use mix asyncio.coroutines and `async def` functions, I
mean I can write `await f()` inside async def to call
asyncio.coroutine `f` and vise versa: I can use `yield from g()`
inside asyncio.coroutine to call `async def g(): ...`.
On 2015-04-22 2:53 PM, Andrew Svetlov wrote:
On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov wrote:
[...]
If we forbid to call `async def` from regualr code how asyncio should
work? I'd like to push `async def` everywhere in asyncio API where
asyncio.coroutine required.
You'
Hi PJ,
On 2015-04-22 3:44 PM, PJ Eby wrote:
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov wrote:
It is an error to pass a regular context manager without ``__aenter__``
and ``__aexit__`` methods to ``async with``. It is a ``SyntaxError``
to use ``async with`` outside of a coroutine.
I
Ludovic,
On 2015-04-22 5:00 PM, Ludovic Gasc wrote:
Not related, but one of my coworkers asked me if with the new syntax it
will be possible to write an async decorator for coroutines.
If I understand correctly new grammar in PEP, it seems to be yes, but could
you confirm ?
There shouldn't be
On 2015-04-22 8:35 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
wrote:
Guido van Rossum wrote:
On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to
wrap a coroutine in a Task, the way its done in asyncio by the Task()
constructor, the loop.create
On 2015-04-22 9:04 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:55 PM, Yury Selivanov
wrote:
On 2015-04-22 8:35 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
wrote:
Guido van Rossum wrote:
On Wed, Apr 22, > OTOH I'm still struggling with
Greg,
On 2015-04-22 7:47 PM, Greg Ewing wrote:
Yury Selivanov wrote:
On the other hand, I hate the idea
of grammatically requiring parentheses for 'await'
expressions. That feels non-pytonic to me.
How is it any different from grammatically requiring
parens in an ordinary fun
On 2015-04-23 8:10 AM, Greg Ewing wrote:
Andrew Svetlov wrote:
From my understanding to use cofunctions I must wrap it with costart
call:
yield from gather(costart(coro1, a1, a2), costart(coro2), fut3)
There are other places in asyncio API those accept coroutines or
futures as parameters, n
On 2015-04-23 9:01 AM, Yury Selivanov wrote:
cocall fut() # instead of just cocall fut()
Should be:
cocall fut() # instead of just cocall fut
Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov wrote:
[]
3.
async with and async for
Bead idea, we clutter the language even more and it is one more
thing every
Hi,
On 2015-04-23 3:30 AM, Wolfgang Langner wrote:
Hi,
most of the time I am a silent reader but in this discussion I must step in.
I use twisted and async stuff a lot over years followed development of
asyncio closely.
First it is good to do differentiate async coroutines from generators. So
Hi Victor,
On 2015-04-23 4:43 AM, Victor Stinner wrote:
[...]
From my understanding, the PEP 3151 simply does not support
asyncio.Future. Am I right?
Greg wants to implement __cocall__ on futures. This way
you'll be able to write
cocall fut() # instead of "await fut"
So you *will have
Hi Wolfgang,
On 2015-04-23 11:57 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky
wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew
On 2015-04-23 11:26 AM, Victor Stinner wrote:
2015-04-23 17:22 GMT+02:00 :
I can live with `cocall fut()` but the difference between `data = yield from
loop.sock_recv(sock, 1024)` and `data = cocall (loop.sock_recv(sock,
1024))()` frustrates me very much.
You didn't answer to my question. My q
Wolfgang,
On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky
wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew
I've updated the PEP 492: https://hg.python.org/peps/rev/352d4f907266
Thanks,
Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ar
Wolfgang,
On 2015-04-23 12:58 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 6:22 PM, Yury Selivanov
wrote:
Wolfgang,
On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner
Hi Barry,
On 2015-04-23 1:51 PM, Barry Warsaw wrote:
On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote:
The updated version of the PEP should be available shortly at
https://www.python.org/dev/peps/pep-0492 and is also pasted in this email.
There's a lot to like about PEP 492. I only
Barry,
On 2015-04-23 2:12 PM, Barry Warsaw wrote:
On Apr 23, 2015, at 02:02 PM, Yury Selivanov wrote:
To my eye 'async def name()', 'async with', 'async for' look
better than 'def async name()', 'with async' and 'for async'.
But th
On 2015-04-23 3:03 AM, Greg Ewing wrote:
Yury Selivanov wrote:
- If it's an object with __await__, return iter(object.__await__())
Is the iter() really needed? Couldn't the contract of
__await__ be that it always returns an iterator?
I wrote it the wrong way. iter() isn't
On 2015-04-23 9:05 PM, Greg Ewing wrote:
Combining those last two lines into one would
require some extra parenthesisation, but I don't
think that's something you're going to be doing
much in practice.
It's a common pattern in asyncio when functions
return futures. It's OK later to refactor
Greg,
On 2015-04-24 4:13 AM, Greg Ewing wrote:
Guido van Rossum wrote:
I think this is the nail in PEP 3152's coffin.
Seems more like a small tack to me. :-)
I've addressed all the issues raised there in
earlier posts.
I'm sorry, but this is ridiculous.
You haven't addressed the issues. W
Guido,
On 2015-04-24 1:03 PM, Guido van Rossum wrote:
*3. syntactic priority of `await`*
Yury, could you tweak the syntax for `await` so that we can write the most
common usages without parentheses? In particular I'd like to be able to
write
```
return await foo()
with await foo() as bar: ...
Victor,
On 2015-04-24 5:32 PM, Victor Stinner wrote:
7. compatibility with asyncio and existing users of it
The current state of the PEP makes types.coroutine() mandatory. If a
generator-based coroutine is not modified with types.coroutine, await
cannot be used on it. To be more concrete: async
Lukasz,
On 2015-04-24 5:37 PM, Łukasz Langa wrote:
(Though maybe we should consider `await for` and `await with`? That would have
the advantage of making it easy to scan for all suspension points by searching
for /await/. But being a verb it doesn't read very well.)
I’m on the fence here.
Hi Guido,
On 2015-04-24 1:03 PM, Guido van Rossum wrote:
*3. syntactic priority of `await`*
Yury, could you tweak the syntax for `await` so that we can write the most
common usages without parentheses? In particular I'd like to be able to
write
```
return await foo()
with await foo() as bar: ..
Hi Arnaud,
On 2015-04-25 4:47 PM, Arnaud Delobelle wrote:
On Tue, 21 Apr 2015 at 18:27 Yury Selivanov wrote:
Hi python-dev,
I'm moving the discussion from python-ideas to here.
The updated version of the PEP should be available shortly
at https://www.python.org/dev/peps/pep-0492
and is
Hi Mark,
On 2015-04-26 4:21 PM, Mark Shannon wrote:
Hi,
I was looking at PEP 492 and it seems to me that no new syntax is
required.
Mark, all your points are explained in the PEP in a great detail:
Looking at the code, it does four things; all of which, or a
functional equivalent, could
On 2015-04-26 5:48 PM, Mark Shannon wrote:
On 26/04/15 21:40, Yury Selivanov wrote:
Hi Mark,
On 2015-04-26 4:21 PM, Mark Shannon wrote:
Hi,
I was looking at PEP 492 and it seems to me that no new syntax is
required.
Mark, all your points are explained in the PEP in a great detail:
I
Brett,
On 2015-04-26 6:09 PM, Brett Cannon wrote:
How is it a burden for people porting Python 2 code? Because they won't
get to name anything 'async' just like anyone supporting older Python 3
versions? Otherwise I don't see how it is of any consequence to people
maintaining 2/3 code as it wi
Paul,
On 2015-04-26 6:25 PM, Paul Sokolovsky wrote:
Ok, so here're 3 points this link gives, with my concerns/questions:
>An alternative idea about new asynchronous iterators and context
>managers was to reuse existing magic methods, by adding an async
>keyword to their declarations:
>[But:]
>
Paul,
On 2015-04-26 7:32 PM, Paul Sokolovsky wrote:
Hello,
On Sun, 26 Apr 2015 18:49:43 -0400
Yury Selivanov wrote:
[]
- it would look confusing
Sorry, "async def __enter__" doesn't look more confusing than
"__aenter__" (vs "__enter__").
I'll up
Paul,
On 2015-04-26 8:17 PM, Paul Sokolovsky wrote:
Hello,
On Sun, 26 Apr 2015 19:45:30 -0400
Yury Selivanov wrote:
[]
Then, is the only logic for proposing __aenter__ is to reinsure
against a situation that someone starts to write async context
manager, forgets that they write async
Hi Greg,
I don't want this: "await a() * b()" to be parsed, it's not meaningful.
Likely you'll see "await await a()" only once in your life, so I'm fine
to use parens for it (moreover, I think it reads better with parens)
Yury
On 2015-04-27 8:52 AM,
ds compatibility problems
(asyncio also has provisional status).
Thank you,
Yury
PEP: 492
Title: Coroutines with async and await syntax
Version: $Revision$
Last-Modified: $Date$
Author: Yury Selivanov
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Apr-2015
Python-Version: 3
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
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
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
Mark,
I'm sorry but you have to view the proposal as a whole. Discussing it
point by point in isolation doesn't make any sense, as with any complex
subject.
Thanks,
Yury
On 2015-04-28 2:44 PM, Mark Shannon wrote:
Hi,
I still think that there are several issues that need addressing with
PE
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
omething like
power: atom_expr ['**' factor]
atom_expr: [AWAIT] atom_expr | atom_trailer
atom_trailer: atom trailer*
will fix 'await await' situation, but does it really need to be fixed?
Yury
On 2015-04-27 9:44 AM, Yury Selivanov wrote:
Hi Greg,
I don't wa
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
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
ith a CO_NATIVE_COROUTINE*
from a regular generator.
Thanks,
Yury
On 2015-04-28 7:26 PM, Yury Selivanov wrote:
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
Greg,
On 2015-04-29 1:40 AM, Greg Ewing wrote:
Yury Selivanov wrote:
I don't want this: "await a() * b()" to be parsed, it's not meaningful.
Why not? If a() is a coroutine that returns a number,
why shouldn't I be able to multiply it by something?
Sorry, I thought
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 cor
On 2015-04-29 5:12 AM, Greg Ewing wrote:
Yury Selivanov wrote:
Looking at the grammar -- the only downside of the current approach
is that
you can't do 'await await fut'. I still think that it reads better with
parens. If we put 'await' to 'factor' term
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:
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
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?
''''''''''''''
Ethan,
On 2015-04-29 11:29 AM, Ethan Furman wrote:
Python is not lisp, and await is not a
function, so parens should not be needed in the common case.
Which common case you mean?
Please see this table
https://www.python.org/dev/peps/pep-0492/#syntax-of-await-expression
Yury
___
Also please see this:
https://hg.python.org/peps/rev/d048458307b7
FWIW, 'await await fut' isn't something that you likely to see in
your life; 'await -fut' is 99.999% just a bug. I'm not sure
why Greg is pushing his Grammar idea so aggressively.
Yury
On 2015-
Ethan,
On 2015-04-29 1:25 PM, Ethan Furman wrote:
cannot also just work and be the same as the parenthesized
version.
Because it does not make any sense.
Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/
Hi Jim,
On 2015-04-29 1:43 PM, Jim J. Jewett wrote:
On Tue Apr 28 23:49:56 CEST 2015, Guido van Rossum quoted PEP 492:
Rationale and Goals
===
Current Python supports implementing coroutines via generators (PEP
342), further enhanced by the ``yield from`` syntax introduced in
Hi Paul,
On 2015-04-29 2:26 PM, Paul Moore wrote:
On 29 April 2015 at 18:43, Jim J. Jewett wrote:
Rationale and Goals
===
Current Python supports implementing coroutines via generators (PEP
342), further enhanced by the ``yield from`` syntax introduced in PEP
380. This approac
Hi Ethan,
On 2015-04-29 2:32 PM, Ethan Furman wrote:
On 04/29, Yury Selivanov wrote:
On 2015-04-29 1:25 PM, Ethan Furman wrote:
cannot also just work and be the same as the parenthesized
version.
Because it does not make any sense.
I obviously don't understand your position that &qu
Hi Nathaniel,
BTW, I'm going to reply to you in the other thread about
context-local objects soon. I have some thoughts on the
topic.
On 2015-04-29 3:14 PM, Nathaniel Smith wrote:
On Apr 29, 2015 11:49 AM, "Yury Selivanov" wrote:
Hi Ethan,
On 2015-04-29 2:32 PM, Ethan Furma
Paul,
On 2015-04-29 3:19 PM, Paul Moore wrote:
On 29 April 2015 at 19:42, Yury Selivanov wrote:
Here's how it might look like (this is the same pseudo-code
but tailored for PEP 492, not a real something)
q = asyncio.Queue(maxsize=100)
async def produce():
# you might wa
On 2015-04-29 3:24 PM, Isaac Schwabacher wrote:
On 15-04-29, Yury Selivanov wrote:
Hi Ethan,
[..]
So I want to make this syntactically incorrect:
Does this need to be a syntax error? -"hello" raises TypeError because str doesn't have a
__neg__, but there's no r
Greg,
On 2015-04-29 6:46 PM, Greg Ewing wrote:
Yury Selivanov wrote:
I'm not sure
why Greg is pushing his Grammar idea so aggressively.
Because I believe that any extra complexity in the grammar
needs a very strong justification. It's complexity in the
core language, like a new k
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
iss
Nathaniel,
On 2015-04-29 7:35 PM, Nathaniel Smith wrote:
What I do feel strongly about
is that whatever syntax we end up with, there should be*some*
accurate human-readable description of*what it is*. AFAICT the PEP
currently doesn't have that.
How to define human-readable description of how u
Guido,
On 2015-04-29 7:52 PM, Guido van Rossum wrote:
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov
wrote:
Nathaniel,
On 2015-04-29 7:35 PM, Nathaniel Smith wrote:
What I do feel strongly about
is that whatever syntax we end up with, there should be*some*
accurate human-readable
Nathaniel,
On 2015-04-29 7:58 PM, Nathaniel Smith wrote:
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov wrote:
Nathaniel,
On 2015-04-29 7:35 PM, Nathaniel Smith wrote:
What I do feel strongly about
is that whatever syntax we end up with, there should be*some*
accurate human-readable
Hi Ethan,
On 2015-04-29 8:21 PM, Ethan Furman wrote:
From the PEP:
Why not a __future__ import
__future__ imports are inconvenient and easy to forget to add.
That is a horrible rationale for not using an import. By that logic we
should have everything in built-ins. ;)
Working example
.
the "New Standard Library Functions"
section.
6. Lot's of small updates and tweaks throughout the PEP.
Thanks,
Yury
PEP: 492
Title: Coroutines with async and await syntax
Version: $Revision$
Last-Modified: $Date$
Author: Yury Selivanov
Status: Draft
Type: Standards T
One more thing to discuss:
7. StopAsyncIteration vs AsyncStopIteration.
I don't have a strong opinion on this, I prefer
the former because it reads better.
There was no consensus on which one we should use.
Thanks,
Yury
___
Python-Dev mailing list
P
Nick,
On 2015-04-29 9:52 PM, Nick Coghlan wrote:
On 30 April 2015 at 10:33, Yury Selivanov wrote:
To really understand all implementation details of this line
you need to read PEP 3156 and experiment with asyncio. There
is no easier way, unfortunately. I can't add a super det
On 2015-04-29 11:01 PM, Nick Coghlan wrote:
On 30 April 2015 at 12:31, Guido van Rossum wrote:
>On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan wrote:
>>
>>[...]
>>Yeah, I'm coming around to the idea. For the async pseudo-keyword, I
>>can see that the proposal only allows its use in cases that
On 2015-04-30 5:16 AM, Greg Ewing wrote:
Yury Selivanov wrote:
3. CO_NATIVE_COROUTINE flag. This enables us to disable
__iter__ and __next__ on native coroutines while maintaining
full backwards compatibility.
I don't think you can honestly claim "full backwards
compatibility&q
On 2015-04-30 1:56 PM, Ethan Furman wrote:
>Why not? Unlike some other languages, Python does not have uniform
>priorities for unary operators, so it's reasonable for some unary
>operations to have a different priority than others, and certain things
>will be SyntaxErrors because of that. E.g.
Jim,
On 2015-04-30 2:41 PM, Jim J. Jewett wrote:
[...]
Does it really permit *making* them [asynchronous calls], or does
it just signal that you will be waiting for them to finish processing
anyhow, and it doesn't need to be a busy-wait?
I does.
Bad phrasing on my part. Is there anything that
On 2015-04-30 7:24 PM, Greg Ewing wrote:
Yury Selivanov wrote:
Well, using next() and iter() on coroutines in asyncio
code is something esoteric. I can't even imagine
why you would want to do that.
I'm talking about the fact that existing generator-
based coroutines that aren&#
ret that differently, and
will try to await those coroutines.
Yury
On 2015-05-01 1:10 PM, Stefan Behnel wrote:
Guido van Rossum schrieb am 01.05.2015 um 17:28:
On Fri, May 1, 2015 at 5:39 AM, Stefan Behnel wrote:
Yury Selivanov schrieb am 30.04.2015 um 03:30:
Asynchr
rable:
class SomeIterable:
def __iter__(self):
return self
async def __next__(self):
return 'spam'
I'm strong -1 on this idea.
Yury
On 2015-05-01 3:03 PM, Stefan Behnel wrote:
Yury Selivanov schrieb am 01.05.2015 um 20:52:
I don't l
On 2015-05-01 3:19 PM, Ethan Furman wrote:
Sure, but the difference is that one would have called __aiter__() first
>and the other __iter__(). Normally, either of the two would not exist, so
>using the wrong loop on an object will just fail. However, after we passed
>that barrier, we already know
On 2015-05-01 3:23 PM, Yury Selivanov wrote:
Let's say it this way: I want to know what I am looking at
when I browse through the code -- an asynchronous iterator,
or a normal iterator. I want an explicit difference between
these protocols, because they are different.
Moreover, the below
On 2015-05-01 4:24 PM, Arnaud Delobelle wrote:
On 1 May 2015 at 20:24, Yury Selivanov wrote:
On 2015-05-01 3:19 PM, Ethan Furman wrote:
[...]
If we must have __aiter__, then we may as well also have __anext__;
besides
being more consistent, it also allows an object to be both a normol
On 2015-05-01 5:37 PM, Jim J. Jewett wrote:
On Thu Apr 30 21:27:09 CEST 2015, Yury Selivanov replied:
On 2015-04-30 2:41 PM, Jim J. Jewett wrote:
Bad phrasing on my part. Is there anything that prevents an
asynchronous call (or waiting for one) without the "async with"?
If so, I
On 2015-05-02 1:04 PM, Ethan Furman wrote:
According to https://www.python.org/dev/peps/pep-0492/#id31:
The [types.coroutine] function applies CO_COROUTINE flag to
generator-function's code object, making it return a coroutine
object.
Further down in https://www.python.org/dev/peps/pep
On 2015-05-02 2:14 PM, Ethan Furman wrote:
On 05/02, Yury Selivanov wrote:
On 2015-05-02 1:04 PM, Ethan Furman wrote:
If I'm understanding this correctly, type.coroutine's only purpose is to add
a flag to a generator object so that await will accept it.
This raises the question of
le: Coroutines with async and await syntax
Version: $Revision$
Last-Modified: $Date$
Author: Yury Selivanov
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Apr-2015
Python-Version: 3.5
Post-History: 17-Apr-2015, 21-Apr-2015, 27-Apr-2015, 29-Apr-2015,
05-
Hi Oscar,
I've updated the PEP with some fixes of the terminology:
https://hg.python.org/peps/rev/f156b272f860
I still think that 'coroutine functions' and 'coroutines'
is a better pair than 'async functions' and 'coroutines'.
First, it's similar to existing terminology for generators.
Second,
Hi Wolfgang,
On 2015-05-05 7:27 AM, Wolfgang wrote:
Hi,
[..]
Even the discussion on python-dev suggests there is some time needed
to finalize all this.
I'd say that:
80% of the recent discussion of the PEP is about terminology.
10% is about whether we should have __future__ import or not.
Paul,
On 2015-05-05 3:14 PM, Paul Moore wrote:
On 5 May 2015 at 19:25, Yury Selivanov wrote:
On 2015-05-05 7:27 AM, Wolfgang wrote:
Even the discussion on python-dev suggests there is some time needed
to finalize all this.
I'd say that:
80% of the recent discussion of the PEP is
On 2015-05-05 3:40 PM, Jim J. Jewett wrote:
On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492.
Where are the following over-simplifications wrong?
(1) The PEP is intended for use (almost exclusively) with
asychronous IO and a scheduler such as the asynchio event loop
On 2015-05-05 4:39 PM, Paul Moore wrote:
Is there anyone who feels they could write a stripped down but working
example of a valid Python event loop*without* the asyncio aspects? Or
is that what David Beazley's talk does?
Yes, in David's talk, where he starts to use 'yield from' you
can simply
On 2015-05-05 5:01 PM, Paul Moore wrote:
On 5 May 2015 at 21:00, Yury Selivanov wrote:
On 2015-05-05 3:40 PM, Jim J. Jewett wrote:
On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492.
Where are the following over-simplifications wrong?
(1) The PEP is intended for use
On 2015-05-05 5:31 PM, Jim J. Jewett wrote:
Tue May 5 21:48:36 CEST 2015, Yury Selivanov wrote:
>As for terminology, I view this discussion differently. It's
>not about the technical details (Python has asymmetric
>coroutines, that's it), but rather on how to disam
Paul,
On 2015-05-05 5:54 PM, Paul Moore wrote:
On 5 May 2015 at 22:38, Yury Selivanov wrote:
n 2015-05-05 5:01 PM, Paul Moore wrote:
On 5 May 2015 at 21:00, Yury Selivanov wrote:
On 2015-05-05 3:40 PM, Jim J. Jewett wrote:
On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated
Jim,
On 2015-05-05 5:09 PM, Jim J. Jewett wrote:
On Tue May 5 21:44:26 CEST 2015,Brett Cannon wrote:
It's not as
complicated as it seems when you realize there is an event loop driving
everything (which people have been leaving out of the conversation since it
doesn't tie into the syntax direc
On 2015-05-05 7:53 PM, Guido van Rossum wrote:
Everybody,
In order to save myself a major headache I'm hereby accepting PEP 492.
I've been following Yury's efforts carefully and I am fully confident that
we're doing the right thing here. There is only so much effort we can put
into clarifying t
Hi Ben,
On 2015-05-06 12:05 AM, Ben Darnell wrote:
On Tue, May 5, 2015 at 3:25 PM, Yury Selivanov
wrote:
Yes, there is no other popular event loop for 3.4 other
than asyncio, that uses coroutines based on generators
(as far as I know).
Tornado supports Python 3.4 and uses generator-based
1 - 100 of 592 matches
Mail list logo
