On 3 May 2015 at 16:24, Steven D'Aprano wrote:
> On Fri, May 01, 2015 at 09:24:47PM +0100, Arnaud Delobelle wrote:
>
>> I'm not convinced that allowing an object to be both a normal and an
>> async iterator is a good thing. It could be a recipe for confusion.
>
> In what way?
>
> I'm thinking tha
On Tue, May 5, 2015 at 1:39 PM, Paul Moore wrote:
>
> It would probably be helpful to have a concrete example of a basic
> event loop that did *nothing* but schedule tasks. No IO waiting or
> similar, just scheduling. I have a gut feeling that event loops are
> more than just asyncio, but without
Paul Moore wrote:
I can't see how you can meaningfully talk about event
loops in a Python context without having *some* term for "things you
wait for".
PEP 3152 was my attempt at showing how you could do that.
--
Greg
___
Python-Dev mailing list
Pyth
Guido van Rossum wrote:
the bytecode generated for
await treats coroutine objects special, just like the bytecode generated
for yield-from treats generator objects special. The special behavior
they have in common is the presence of send() and throw() methods,
I don't think that's quit accura
On 6 May 2015 at 09:20, Greg Ewing wrote:
>> That doesn't cover any of the higher level abstractions like tasks or
>> futures (at least not by those names or with those interfaces).
>
> Because a minimal event loop doesn't *need* those.
It doesn't *need* them, but as abstractions they allow easie
Hi Yury,
On 05.05.2015 20:25, Yury Selivanov wrote:
>>
>> We forget to address the major problems here. How can someone in a
>> "sync" script use this async stuff easy. How can async and sync stuff
>> cooperate and we don't need to rewrite the world for async stuff.
>> How can a normal user acce
Paul Moore wrote:
What about Greg Ewing's example?
http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/yf_current/Examples/Scheduler/scheduler.txt
That doesn't cover any of the higher level abstractions like tasks or
futures (at least not by those names or with those interfaces).
B
Paul Moore wrote:
It would probably be helpful to have a concrete example of a basic
event loop that did *nothing* but schedule tasks. No IO waiting or
similar, just scheduling.
Take a look at the example I developed when working
on the yield-from pep:
http://www.cosc.canterbury.ac.nz/greg.ewi
On Tue, May 5, 2015 at 3:01 PM, Nathaniel Smith wrote:
On May 5, 2015 2:14 PM, "Guido van Rossum" wrote:
> >
> > In the PEP 492 world, these concepts map as follows:
> >
> > - Future translates to "something with an __await__ method" (and asyncio
> Futures are trivially made compliant by definin
On May 5, 2015 2:14 PM, "Guido van Rossum" wrote:
>
> In the PEP 492 world, these concepts map as follows:
>
> - Future translates to "something with an __await__ method" (and asyncio
Futures are trivially made compliant by defining Future.__await__ as an
alias for Future.__iter__);
>
> - "asyncio
On Tue, May 5, 2015 at 2:29 PM, Paul Moore wrote:
> On 5 May 2015 at 22:12, Guido van Rossum wrote:
> > I apologize for the confusing documentation. We need more help from
> > qualified tech writers! Writing PEP 3156 was a huge undertaking for me;
> > after that I was exhausted and did not want
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 disambiguate
>coroutines impleme
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 disambiguate
> coroutines implemented with generators and yield-from, from
>
On 5 May 2015 at 22:12, Guido van Rossum wrote:
> I apologize for the confusing documentation. We need more help from
> qualified tech writers! Writing PEP 3156 was a huge undertaking for me;
> after that I was exhausted and did not want to take on writing the end user
> documentation as well, so
On 5 May 2015 at 21:57, Guido van Rossum wrote:
> On Tue, May 5, 2015 at 1:39 PM, Paul Moore wrote:
>>
>> It's very hard to separate coroutines from asyncio, because there's no
>> other example (not even a toy one) to reason about.
>
> What about Greg Ewing's example?
> http://www.cosc.canterbury
On Tue, May 5, 2015 at 1:44 PM, Paul Moore wrote:
> [Guido]
> > The run_in_executor call is not callback-based -- the confusion probably
> > stems from the name of the function argument ('callback'). It actually
> > returns a Future representing the result (or error) of an operation,
> where
> >
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 Tue, May 5, 2015 at 1:39 PM, Paul Moore wrote:
> It's very hard to separate coroutines from asyncio, because there's no
> other example (not even a toy one) to reason about.
>
What about Greg Ewing's example?
http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/yf_current/Examples/Sc
Jumping in to correct one fact.
On Tue, May 5, 2015 at 12:44 PM, Brett Cannon wrote:
>
> On Tue, May 5, 2015 at 3:14 PM Paul Moore wrote:
>
>> Well, twisted always had defer_to_thread. Asyncio has run_in_executor,
>> but that seems to be callback-based rather than coroutine-based?
>>
>
> Yep.
>
On 5 May 2015 at 21:38, Guido van Rossum wrote:
> Jumping in to correct one fact.
>
> On Tue, May 5, 2015 at 12:44 PM, Brett Cannon wrote:
>>
>>
>> On Tue, May 5, 2015 at 3:14 PM Paul Moore wrote:
>>>
>>> Well, twisted always had defer_to_thread. Asyncio has run_in_executor,
>>> but that seems t
(Yury gave similar responses, so (a) I'll just respond here, and (b)
it's encouraging that you both responded so quickly with the same
message)
On 5 May 2015 at 20:44, Brett Cannon wrote:
>> That's not to say that everything needs to be beginner-friendly, but
>> it *does* mean that it's hard for
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 about termi
On Tue, May 5, 2015 at 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 discuss
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 about terminology.
> 10% is about whether we shou
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.
tds333 gmail.com gmail.com> writes:
>
> Hi,
>
> still watching progress here. Read all posts and changes.
>
> Everything improved and I know it is a lot of work. Thx for doing this.
>
> But I still think this PEP goes to far.
>
> [...]
>
> We forget to address the major problems here. How
Hi,
still watching progress here. Read all posts and changes.
Everything improved and I know it is a lot of work. Thx for doing this.
But I still think this PEP goes to far.
1. To have "native coroutines" and await, __await__ is very good and
useful. Also for beginners to see and mark coroutine
Hi,
still watching progress here. Read all posts and changes.
Everything improved and I know it is a lot of work. Thx for doing this.
But I still think this PEP goes to far.
1. To have "native coroutines" and await, __await__ is very good and
useful. Also for beginners to see and mark coroutine
On Fri, May 01, 2015 at 09:24:47PM +0100, Arnaud Delobelle wrote:
> I'm not convinced that allowing an object to be both a normal and an
> async iterator is a good thing. It could be a recipe for confusion.
In what way?
I'm thinking that the only confusion would be if you wrote "async for"
ins
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
>> iterator
>> and an asynch iterator.
>
>
> And
On 1 May 2015 at 21:27, Yury Selivanov wrote:
> 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__;
besi
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
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 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 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
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
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
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
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 Thu, Apr 30, 2015 at 4: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 coroutin
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't decorated with
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't decorated with
@coroutine won't be able to call new ones
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" as long as ther
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" as long as there are some combinations
of old-style and n
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
Hi python-dev,
New version of the PEP is attached. Summary of updates:
1. Terminology:
- *native coroutine* term is used for "async def" functions.
- *generator-based coroutine* term is used for PEP 380
coroutines used in asyncio.
- *coroutine* is used when *native coroutine* or
*generator b
54 matches
Mail list logo
