On 24 April 2015 at 09:34, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
and after the refactoring it becomes
cocall await(cocall f(x))
That doesn't look so bad to me.
I've not been following this discussion (and coroutines make my head
hurt) but this idiom looks like it's bound to result
Victor Stinner wrote:
Oh, I missed something in the PEP 3152: a obj__cocall__() method can
be an iterator/generator, it can be something different than a
cofunction.
In fact, it *can't* be cofunction. It's part of the
machinery for implementing cofunctions.
It's not easy to understand the
Yury Selivanov wrote:
It's a common pattern in asyncio when functions
return futures. It's OK later to refactor those
functions to coroutines *and* vice-versa. This
is a fundamental problem for PEP 3152 approach.
Hmmm. So you have an ordinary function that returns
a future, and you want to
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.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Paul Moore wrote:
On 24 April 2015 at 09:34, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
cocall await(cocall f(x))
That doesn't look so bad to me.
I've not been following this discussion (and coroutines make my head
hurt) but this idiom looks like it's bound to result in people getting
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.
On Fri, Apr 24, 2015 at 11:34 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Yury Selivanov wrote:
It's a common pattern in asyncio when functions
return futures. It's OK later to refactor those
functions to coroutines *and* vice-versa. This
is a fundamental problem for PEP 3152
On Apr 23, 2015, at 8:22 AM, andrew.svet...@gmail.com wrote:
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.
This is unacceptable. None of the existing
On 2015-04-23 11:26 AM, Victor Stinner wrote:
2015-04-23 17:22 GMT+02:00 andrew.svet...@gmail.com:
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
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
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.
—
Sent from Mailbox
On Thu, Apr 23, 2015 at 4:09 PM, Victor Stinner victor.stin...@gmail.com
wrote:
(I prefer
On Thu, 23 Apr 2015 09:58:33 -0700
Guido van Rossum gu...@python.org wrote:
I think this is the nail in PEP 3152's coffin.
If you only put one nail, it might manage to get out.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
2015-04-23 17:22 GMT+02:00 andrew.svet...@gmail.com:
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 question is: is it
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:
I think this is the nail in PEP 3152's coffin.
On Thu, Apr 23, 2015 at 9:54 AM, Yury Selivanov yselivanov...@gmail.com
wrote:
I've updated the PEP 492: https://hg.python.org/peps/rev/352d4f907266
Thanks,
Yury
___
Python-Dev mailing list
Then blow it up like Duck Dynasty does.
On April 23, 2015 12:07:46 PM CDT, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 23 Apr 2015 09:58:33 -0700
Guido van Rossum gu...@python.org wrote:
I think this is the nail in PEP 3152's coffin.
If you only put one nail, it might manage to get out.
Hi,
2015-04-23 17:54 GMT+02:00 Yury Selivanov yselivanov...@gmail.com:
Greg wants to implement __cocall__ on futures. This way
you'll be able to write
cocall fut() # instead of await fut
Oh, I missed something in the PEP 3152: a obj__cocall__() method can
be an iterator/generator, it
Victor Stinner wrote:
You didn't answer to my question. My question is: is it possible to
implement Future.__cocall__() since yield is defined in cofunctions.
If it's possible, can you please show how? (Show me the code!)
The implementation of a __cocall__ method is *not* a
cofunction, it's
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
andrew.svet...@gmail.com wrote:
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.
That's not the way it would be done. In a PEP-3152-ified
version of asyncio,
(I prefer to start a new thread, the previous one is too long for me :-))
Hi,
I'm still trying to understand how the PEP 3152 would impact asyncio.
Guido suggests to replace yield from fut with cocall fut() (add
parenthesis) and so add a __cocall__() method to asyncio.Future.
Problem: PEP 3152
Victor Stinner wrote:
I'm still trying to understand how the PEP 3152 would impact asyncio.
Guido suggests to replace yield from fut with cocall fut() (add
parenthesis) and so add a __cocall__() method to asyncio.Future.
Problem: PEP 3152 says A cofunction (...) does not contain any yield
or
Yury Selivanov wrote:
Another problem is functions that return future:
def do_something():
...
return fut
With Greg's idea to call it you would do:
cocall (do_something())()
That means that you can't refactor your do_something
function and make it a coroutine.
There's no
23 matches
Mail list logo
