On 5/1/2015 9:59 AM, Guido van Rossum wrote:
I think coroutine is the name of a concept, not a specific
implementation.
Cheers,
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
The high-level answer to this is, like yield, the function temporarily returns
all the way up the stack to the caller who intends to advance the
iterator/async function. This is typically the event loop, and the main
confusion here comes when the loop is implicit.
If you explicitly define an
Yury Selivanov schrieb am 01.05.2015 um 20:52:
I don't like the idea of combining __next__ and __anext__.
Ok, fair enough. So, how would you use this new protocol manually then?
Say, I already know that I won't need to await the next item that the
iterator will return. For normal iterators, I
On Fri, May 1, 2015 at 5:39 AM, Stefan Behnel stefan...@behnel.de wrote:
Yury Selivanov schrieb am 30.04.2015 um 03:30:
Asynchronous Iterators and async for
--
An *asynchronous iterable* is able to call asynchronous code in its
*iter* implementation,
On 1 May 2015 at 16:31, Guido van Rossum gu...@python.org wrote:
On Fri, May 1, 2015 at 5:50 AM, Stefan Behnel stefan...@behnel.de wrote:
Yury Selivanov schrieb am 30.04.2015 um 03:30:
1. Terminology:
- *native coroutine* term is used for async def functions.
When I read native, I think
On Fri, May 1, 2015 at 5:50 AM, Stefan Behnel stefan...@behnel.de wrote:
Yury Selivanov schrieb am 30.04.2015 um 03:30:
1. Terminology:
- *native coroutine* term is used for async def functions.
When I read native, I think of native (binary) code. So native
coroutine sounds like it's
Nathaniel Smith wrote:
If await acted like -, then this would be
await (x ** 2)
But with the proposed grammar, it's instead
(await x) ** 2
Ah, I had missed that!
This is a *good* argument for Yuri's grammar.
I withdraw my objection now.
--
Greg
ACTIVITY SUMMARY (2015-04-24 - 2015-05-01)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4841 (+27)
closed 31025 (+25)
total 35866 (+52)
Open issues
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:
Asynchronous Iterators and async for
--
An *asynchronous iterable* is able to call asynchronous code in
On Fri, May 1, 2015 at 8:55 AM, Gustavo Carneiro gjcarne...@gmail.com
wrote:
On 1 May 2015 at 16:31, Guido van Rossum gu...@python.org wrote:
On Fri, May 1, 2015 at 5:50 AM, Stefan Behnel stefan...@behnel.de
wrote:
Yury Selivanov schrieb am 30.04.2015 um 03:30:
1. Terminology:
-
On Fri, 1 May 2015 13:10:01 -0700
Guido van Rossum gu...@python.org wrote:
On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett jimjjew...@gmail.com wrote:
If there are more tasks than executors, yield is a way to release your
current executor and go to the back of the line. I'm pretty sure I
On 2015-05-01 4:24 PM, Arnaud Delobelle wrote:
On 1 May 2015 at 20:24, Yury Selivanov yselivanov...@gmail.com 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
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 code is a perfectly valid, infinite
iterable:
On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett jimjjew...@gmail.com wrote:
If there are more tasks than executors, yield is a way to release your
current executor and go to the back of the line. I'm pretty sure I
saw several examples of that style back when coroutines were first
discussed.
On Fri, May 1, 2015 at 1:22 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 1 May 2015 13:10:01 -0700
Guido van Rossum gu...@python.org wrote:
On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett jimjjew...@gmail.com
wrote:
If there are more tasks than executors, yield is a way to
On 05/01, Guido van Rossum wrote:
On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett jimjjew...@gmail.com wrote:
So does this mean that yield should NOT be used just to yield control
if a task isn't blocked? (e.g., if its next step is likely to be
long, or low priority.) Or even that it
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 Fri, May 1, 2015 at 2:59 PM, Guido van Rossum gu...@python.org wrote:
On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett jimjjew...@gmail.com wrote:
On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum gu...@python.org
wrote:
(Guido:) Actually that's not even wrong. When using generators as
On Fri, May 1, 2015 at 12:24 PM, Ethan Furman et...@stoneleaf.us wrote:
On 05/01, Guido van Rossum wrote:
On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett jimjjew...@gmail.com
wrote:
So does this mean that yield should NOT be used just to yield control
if a task isn't blocked? (e.g., if
On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett jimjjew...@gmail.com wrote:
On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum gu...@python.org
wrote:
(me:)
A badly worded attempt to say
Normal generator: yield (as opposed to return) means
that the function isn't done, and there may be
Yury Selivanov schrieb am 01.05.2015 um 20:52:
I don't like the idea of combining __next__ and __anext__.
In this case explicit is better than implicit. __next__
returning coroutines is a perfectly normal thing for a
normal 'for' loop (it wouldn't to anything with them),
whereas 'async for'
On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum gu...@python.org wrote:
(me:)
A badly worded attempt to say
Normal generator: yield (as opposed to return) means
that the function isn't done, and there may be more
things to return later.
but an asynchronous (PEP492) coroutine is primarily
Stefan,
I don't like the idea of combining __next__ and __anext__.
In this case explicit is better than implicit. __next__
returning coroutines is a perfectly normal thing for a
normal 'for' loop (it wouldn't to anything with them),
whereas 'async for' will interpret that differently, and
will
On 05/01, Stefan Behnel wrote:
Yury Selivanov schrieb am 01.05.2015 um 20:52:
I don't like the idea of combining __next__ and __anext__.
In this case explicit is better than implicit. __next__
returning coroutines is a perfectly normal thing for a
normal 'for' loop (it wouldn't to anything
On Fri, May 1, 2015 at 6:14 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
Adam Bartoš writes:
Unfortunately, it doesn't work. With PYTHONIOENCODING=utf-8, the
sys.std* streams are created with utf-8 encoding (which doesn't
help on Windows since they still don't use ReadConsoleW and
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'm missing something important. Either way, I would
On Fri, May 1, 2015 at 4:10 PM, Guido van Rossum gu...@python.org wrote:
On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett jimjjew...@gmail.com wrote:
If there are more tasks than executors, yield is a way to release your
current executor and go to the back of the line. I'm pretty sure I
saw
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'm missing
Yury Selivanov schrieb am 30.04.2015 um 03:30:
Asynchronous Iterators and async for
--
An *asynchronous iterable* is able to call asynchronous code in its
*iter* implementation, and *asynchronous iterator* can call
asynchronous code in its *next* method.
Yury Selivanov schrieb am 30.04.2015 um 03:30:
1. Terminology:
- *native coroutine* term is used for async def functions.
When I read native, I think of native (binary) code. So native
coroutine sounds like it's implemented in some compiled low-level
language. That might be the case (certainly
On Wed, Apr 29, 2015 at 06:12:37PM -0700, Guido van Rossum wrote:
On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 30 April 2015 at 10:21, Ethan Furman et...@stoneleaf.us wrote:
From the PEP:
Why not a __future__ import
__future__ imports are
On Wed, Apr 29, 2015 at 07:31:22PM -0700, Guido van Rossum wrote:
Ah, but here's the other clever bit: it's only interpreted this way
*inside* a function declared with 'async def'. Outside such functions,
'await' is not a keyword, so that grammar rule doesn't trigger. (Kind of
similar to the
On 1 May 2015 at 12:54, Steven D'Aprano st...@pearwood.info wrote:
You mean we could write code like this?
def await(x):
...
if condition:
async def spam():
await (eggs or cheese)
else:
def spam():
await(eggs or cheese)
I must admit that's kind of cool,
33 matches
Mail list logo
