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. W
On Fri, Apr 24, 2015 at 11:34 AM, Greg Ewing
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 approach.
>
>
> Hmmm. So
Paul Moore wrote:
On 24 April 2015 at 09:34, Greg Ewing 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
the idea that you scatter "c
On 24 April 2015 at 09:34, Greg Ewing 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 in people getting
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 t
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 who
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
https://mail.python.
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
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 fundam
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 an
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, sock
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
Hi,
2015-04-23 17:54 GMT+02:00 Yury Selivanov :
> 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 can be something dif
Then blow it up like Duck Dynasty does.
On April 23, 2015 12:07:46 PM CDT, Antoine Pitrou wrote:
>On Thu, 23 Apr 2015 09:58:33 -0700
>Guido van Rossum 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.
>
>
>___
On Thu, 23 Apr 2015 09:58:33 -0700
Guido van Rossum 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
https://mail.python.
I think this is the nail in PEP 3152's coffin.
On Thu, Apr 23, 2015 at 9:54 AM, Yury Selivanov
wrote:
> I've updated the PEP 492: https://hg.python.org/peps/rev/352d4f907266
>
> Thanks,
> Yury
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
>
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:
https://mail.python.org/mailman/options/python-dev/ar
On 2015-04-23 11:26 AM, Victor Stinner wrote:
2015-04-23 17:22 GMT+02:00 :
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 q
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
2015-04-23 17:22 GMT+02:00 :
> 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 possible to
implement Fut
> 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
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
wrote:
> (I prefer to start a new thread,
(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 315
23 matches
Mail list logo
