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 co
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 a
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 ev
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
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 wo
On Fri, May 1, 2015 at 4:10 PM, Guido van Rossum wrote:
> On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett 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
On Fri, May 1, 2015 at 1:22 PM, Antoine Pitrou wrote:
> On Fri, 1 May 2015 13:10:01 -0700
> Guido van Rossum wrote:
> > On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett
> wrote:
> >
> > > If there are more tasks than executors, yield is a way to release your
> > > current executor and go to the b
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
iterato
On Fri, 1 May 2015 13:10:01 -0700
Guido van Rossum wrote:
> On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett 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
On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett 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.
>
Could you dig u
On Fri, May 1, 2015 at 12:24 PM, Ethan Furman wrote:
> On 05/01, Guido van Rossum wrote:
> > On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett
> 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
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 code i
On Fri, May 1, 2015 at 12:49 PM, Ron Adam wrote:
>
> Another useful async function might be...
>
>async def yielding():
>pass
>
> In a routine is taking very long time, just inserting "await yielding()"
> in the long calculation would let other awaitables run.
>
> That's really up to
On 05/01/2015 07:54 AM, Steven D'Aprano wrote:
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 gra
On Fri, May 1, 2015 at 2:59 PM, Guido van Rossum wrote:
> On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett wrote:
>>
>> On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum
>> wrote:
>>
>> (Guido:)> Actually that's not even wrong. When using generators as
>> coroutines, PEP 342
>> > style, "yield" m
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 05/01, Guido van Rossum wrote:
> On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett 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 wouldn't be considere
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:
c
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 a
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 f
On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett wrote:
> On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum
> 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 retur
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 t
On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum 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 saying
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 async
On Fri, May 1, 2015 at 8:55 AM, Gustavo Carneiro
wrote:
>
>
>
> On 1 May 2015 at 16:31, Guido van Rossum wrote:
>
>> On Fri, May 1, 2015 at 5:50 AM, Stefan Behnel
>> wrote:
>>
>>> Yury Selivanov schrieb am 30.04.2015 um 03:30:
>>> > 1. Terminology:
>>> > - *native coroutine* term is used for "a
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 wit
On 1 May 2015 at 16:31, Guido van Rossum wrote:
> On Fri, May 1, 2015 at 5:50 AM, Stefan Behnel 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)
On Fri, May 1, 2015 at 5:50 AM, Stefan Behnel 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 implemente
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 its
> > *iter* implementation, and *a
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 (cer
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* m
On 1 May 2015 at 12:54, Steven D'Aprano 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, but I'
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 t
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 wrote:
>
> > On 30 April 2015 at 10:21, Ethan Furman wrote:
> > > From the PEP:
> > >
> > >> Why not a __future__ import
> > >>
> > >> __future__ imports are inconvenient and easy to
On Fri, May 1, 2015 at 6:14 AM, Stephen J. Turnbull
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
> > Write
35 matches
Mail list logo
