On 3 May 2015 at 16:24, Steven D'Aprano st...@pearwood.info 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
On 6 May 2015 at 09:20, Greg Ewing greg.ew...@canterbury.ac.nz 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
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).
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 access the
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
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:
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
On Tue, May 5, 2015 at 1:39 PM, Paul Moore p.f.mo...@gmail.com 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
tds333 at gmail.com tds333 at 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
On May 5, 2015 2:14 PM, Guido van Rossum gu...@python.org 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__);
-
On Tue, May 5, 2015 at 3:01 PM, Nathaniel Smith n...@pobox.com wrote:
On May 5, 2015 2:14 PM, Guido van Rossum gu...@python.org 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
On Tue, May 5, 2015 at 3:14 PM Paul Moore p.f.mo...@gmail.com wrote:
On 5 May 2015 at 19:25, Yury Selivanov yselivanov...@gmail.com 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:
On 5 May 2015 at 19:25, Yury Selivanov yselivanov...@gmail.com 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
Paul,
On 2015-05-05 3:14 PM, Paul Moore wrote:
On 5 May 2015 at 19:25, Yury Selivanov yselivanov...@gmail.com 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
(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 br...@python.org wrote:
That's not to say that everything needs to be beginner-friendly, but
it *does* mean that
On 5 May 2015 at 21:38, Guido van Rossum gu...@python.org wrote:
Jumping in to correct one fact.
On Tue, May 5, 2015 at 12:44 PM, Brett Cannon br...@python.org wrote:
On Tue, May 5, 2015 at 3:14 PM Paul Moore p.f.mo...@gmail.com wrote:
Well, twisted always had defer_to_thread. Asyncio has
Jumping in to correct one fact.
On Tue, May 5, 2015 at 12:44 PM, Brett Cannon br...@python.org wrote:
On Tue, May 5, 2015 at 3:14 PM Paul Moore p.f.mo...@gmail.com wrote:
Well, twisted always had defer_to_thread. Asyncio has run_in_executor,
but that seems to be callback-based rather than
On Tue, May 5, 2015 at 1:39 PM, Paul Moore p.f.mo...@gmail.com 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?
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
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.
On Tue, May 5, 2015 at 1:44 PM, Paul Moore p.f.mo...@gmail.com 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,
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
On Tue, May 5, 2015 at 2:29 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 5 May 2015 at 22:12, Guido van Rossum gu...@python.org 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
On 5 May 2015 at 21:57, Guido van Rossum gu...@python.org wrote:
On Tue, May 5, 2015 at 1:39 PM, Paul Moore p.f.mo...@gmail.com 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?
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
new
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
On 1 May 2015 at 21:27, Yury Selivanov yselivanov...@gmail.com wrote:
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
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 be both a normol
iterator
and an asynch
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
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
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 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 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
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'
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
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
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
On Thu, Apr 30, 2015 at 4:24 PM, Greg Ewing greg.ew...@canterbury.ac.nz
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-
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
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
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 there
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
49 matches
Mail list logo
