Hi,
On 2015-04-23 3:30 AM, Wolfgang Langner wrote:
Hi,
most of the time I am a silent reader but in this discussion I must step in.
I use twisted and async stuff a lot over years followed development of
asyncio closely.
First it is good to do differentiate async coroutines from generators. So
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 Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com
wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov
lol @ the fact that the type hints are breaking github's syntax highlighter
:)
On 23 April 2015 at 14:44, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
On Thu, 23 Apr 2015 14:48:58 +0200
Wolfgang Langner tds333+py...@gmail.com wrote:
Hello,
On Thu, Apr 23, 2015 at 11:59 AM, Paul
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov andrew.svet...@gmail.com wrote:
[]
3.
async with and async for
Bead idea, we clutter the language
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
Hello,
On Thu, 23 Apr 2015 15:25:30 +0100
Harry Percival harry.perci...@gmail.com wrote:
lol @ the fact that the type hints are breaking github's syntax
highlighter :)
What one can expect from software written in Ruby? ;-)
--
Best regards,
Paul
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
Hi Wolfgang,
On 2015-04-23 11:57 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com
wrote:
Hello,
On
Thanks for advice.
On 04/23/2015 05:07 PM, Brett Cannon wrote:
A better place to ask this question is the core-mentorship mailing
list which was set up specifically to help people contribute to Python.
On Thu, Apr 23, 2015 at 9:07 AM Leonid Kokorev ldvc...@gmail.com
mailto:ldvc...@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.
—
Sent from Mailbox
On Thu, Apr 23, 2015 at 4:09 PM, Victor Stinner victor.stin...@gmail.com
wrote:
(I prefer
Wolfgang,
On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com
wrote:
Hello,
On Thu,
On Thu, Apr 23, 2015 at 6:22 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Wolfgang,
On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On
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
Hi Barry,
On 2015-04-23 1:51 PM, Barry Warsaw wrote:
On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote:
The updated version of the PEP should be available shortly at
https://www.python.org/dev/peps/pep-0492 and is also pasted in this email.
There's a lot to like about PEP 492. I only want
On Apr 23, 2015, at 02:02 PM, Yury Selivanov wrote:
To my eye 'async def name()', 'async with', 'async for' look
better than 'def async name()', 'with async' and 'for async'.
But that's highly subjective.
Would you be willing to add this as an alternative to the PEP, under the Why
async def
On 2015-04-23 18:51, Barry Warsaw wrote:
On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote:
The updated version of the PEP should be available shortly at
https://www.python.org/dev/peps/pep-0492 and is also pasted in this email.
There's a lot to like about PEP 492. I only want to mildly
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
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com
wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov
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.
On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote:
The updated version of the PEP should be available shortly at
https://www.python.org/dev/peps/pep-0492 and is also pasted in this email.
There's a lot to like about PEP 492. I only want to mildly bikeshed a bit on
the proposed new syntax.
Why
On Apr 23, 2015, at 10:51 AM, Barry Warsaw ba...@python.org wrote:
(I have mild concerns about __a*__ magic methods, since I think they'll be
harder to visually separate, but here the PEP does describe the __async_*__
alternatives.)
Has it been historically a problem with __iadd__ vs
On 2015-04-23 3:03 AM, Greg Ewing wrote:
Yury Selivanov wrote:
- If it's an object with __await__, return iter(object.__await__())
Is the iter() really needed? Couldn't the contract of
__await__ be that it always returns an iterator?
I wrote it the wrong way. iter() isn't needed, you're
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
Wolfgang,
On 2015-04-23 12:58 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 6:22 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Wolfgang,
On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Wolfgang,
Barry,
On 2015-04-23 2:12 PM, Barry Warsaw wrote:
On Apr 23, 2015, at 02:02 PM, Yury Selivanov wrote:
To my eye 'async def name()', 'async with', 'async for' look
better than 'def async name()', 'with async' and 'for async'.
But that's highly subjective.
Would you be willing to add this as
On Thu, Apr 23, 2015 at 03:25:30PM +0100, Harry Percival wrote:
lol @ the fact that the type hints are breaking github's syntax highlighter
:)
That just tells us that Github's syntax highlighter has been broken for
over five years. Function annotations go back to Python 3.0, more than
five
On Wed, Apr 22, 2015 at 5:45 PM, Guido van Rossum gu...@python.org wrote:
Given that even if Difference existed, and even if we had a predefined
type alias for Difference[Iterable[str], str], you' still have to remember
to mark up all those functions with that annotation. It almost sounds
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,
Hello,
On Thu, 23 Apr 2015 09:15:44 -0400
Daniel Holth dho...@gmail.com wrote:
[]
Also ask why no one used type specifier, they are possible since
Python 3.0 ?
Because it is the wrong way for Python.
That's an example of how perceptions differ. In my list, everyone(*)
uses them -
A better place to ask this question is the core-mentorship mailing list
which was set up specifically to help people contribute to Python.
On Thu, Apr 23, 2015 at 9:07 AM Leonid Kokorev ldvc...@gmail.com wrote:
Hello.
My name is Leonid. I'm very interested in Python programming language.
I'm
On Thu, Apr 23, 2015 at 9:55 AM, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
On Thu, 23 Apr 2015 09:15:44 -0400
Daniel Holth dho...@gmail.com wrote:
[]
Also ask why no one used type specifier, they are possible since
Python 3.0 ?
Because it is the wrong way for Python.
That's
Yury Selivanov wrote:
I think there is another way... instead of pushing
GET_ITER
...
YIELD_FROM
opcodes, we'll need to replace GET_ITER with another one:
GET_ITER_SPECIAL
...
YIELD_FROM
I'm lost. What Python code are you suggesting this
would be generated from?
--
Greg
Yury Selivanov wrote:
- If it's an object with __await__, return iter(object.__await__())
Is the iter() really needed? Couldn't the contract of
__await__ be that it always returns an iterator?
--
Greg
___
Python-Dev mailing list
It's not the first time someone is confused by the server example of
https://docs.python.org/3/library/socketserver.html
where the receiving side is not making a loop over recv.
Moreover the documentation contains a misleading description of what really
happens:
The difference is that the
PJ Eby wrote:
I find this a little weird. Why not just have `with` and `for` inside
a coroutine dynamically check the iterator or context manager, and
either behave sync or async accordingly? Why must there be a
*syntactic* difference?
It depends on whether you think it's important to
have a
On 4/22/2015 8:45 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 2:38 PM, Chris Barker chris.bar...@noaa.gov
mailto:chris.bar...@noaa.gov wrote:
On Tue, Apr 21, 2015 at 11:32 PM, Terry Reedy tjre...@udel.edu
mailto:tjre...@udel.edu wrote:
I was just thinking today that
On 2015-04-23 8:10 AM, Greg Ewing wrote:
Andrew Svetlov wrote:
From my understanding to use cofunctions I must wrap it with costart
call:
yield from gather(costart(coro1, a1, a2), costart(coro2), fut3)
There are other places in asyncio API those accept coroutines or
futures as parameters,
On 2015-04-23 9:01 AM, Yury Selivanov wrote:
cocall fut() # instead of just cocall fut()
Should be:
cocall fut() # instead of just cocall fut
Yury
___
Python-Dev mailing list
Python-Dev@python.org
* Wolfgang Langner tds333+py...@gmail.com [2015-04-23 10:43:52 +0200]:
2. Using it in the language as part of the function signature, my first
thought was oh good, then I changed my mind
to: oh it can be very ugly and unreadable, it is the wrong place.
Now I am against it, best is, if I
Hello,
On Thu, 23 Apr 2015 10:43:52 +0200
Wolfgang Langner tds333+py...@gmail.com wrote:
[]
Also ask why no one used type specifier, they are possible since
Python 3.0 ?
Because it is the wrong way for Python.
That's an example of how perceptions differ. In my list, everyone(*)
uses them -
Hello.
My name is Leonid. I'm very interested in Python programming language.
I'm sending this letter to the python-dev mailing list in order to get
any task, that I could perform.
I want to help my community and improve my skills.
If anybody has not very complicated task, please email me at
Hello,
On Thu, 23 Apr 2015 20:39:51 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Paul Sokolovsky wrote:
And having both asymmetric and symmetric
would quite confusing, especially that symmetric are more powerful
and asymmetric can be easily implemented in terms of symmetric using
(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
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov andrew.svet...@gmail.com wrote:
[]
3.
async with and async for
Bead idea, we clutter the language even more and it is one more
thing every newbie could do wrong.
for x in y:
result = await f()
is enough, every 'async'
Victor Stinner wrote:
A huge part of the asyncio module is based on yield from fut where fut is
a Future object.
How do you write this using the PEP 3152? Do you need to call an artifical
method like cocall fut.return_self() where the return_self() method simply
returns fut?
In a PEP 3152
Victor Stinner wrote:
Using a custom name like cofunction may confuse users coming from other
programming languages. I prefer to keep coroutine, but I agree that we
should make some effort to define the different categories of Python
coroutines.
I should perhaps point out that cofunction is
Yury Selivanov wrote:
I think that the problem of forgetting 'yield from' is a bit
exaggerated. Yes, I myself forgot 'yield from' once or twice. But that's
it, it has never happened since.
I think it's more likely to happen when you start with
an ordinary function, then discover that it needs
Ludovic Gasc wrote:
Not related, but one of my coworkers asked me if with the new syntax it
will be possible to write an async decorator for coroutines.
This is certainly possible with PEP 3152. The decorator
just needs to be an ordinary function whose return
value is a cofunction.
--
Greg
Hi,
having a lot experience with Python beginners and people programming
Java/Python I have also an opinion about this. ;-)
First reaction was, oh good. Then I read every thread and comment about it,
looked at a lot internal code give all some time
and the result is:
I found a lot of code
On Thu, Apr 23, 2015 at 10:30 AM, Wolfgang Langner
tds333+py...@gmail.com wrote:
Hi,
most of the time I am a silent reader but in this discussion I must step in.
I use twisted and async stuff a lot over years followed development of
asyncio closely.
First it is good to do differentiate
On Thu, 23 Apr 2015 09:21:11 +0200
Andrea Griffini agr...@tin.it wrote:
It's not the first time someone is confused by the server example of
https://docs.python.org/3/library/socketserver.html
where the receiving side is not making a loop over recv.
This is a trivial example indeed. If you
Hi,
most of the time I am a silent reader but in this discussion I must step in.
I use twisted and async stuff a lot over years followed development of
asyncio closely.
First it is good to do differentiate async coroutines from generators. So
everyone can see it and have this in mind
and don't
Paul Sokolovsky wrote:
And having both asymmetric and symmetric
would quite confusing, especially that symmetric are more powerful and
asymmetric can be easily implemented in terms of symmetric using
continuation-passing style.
You can also use a trampoline of some kind to
relay values back
Hi,
I agree with most of Wolfgang's points below. As a data point, I
haven't used asyncio for anything real (despite having approved the
PEP!), but I have some extensive prior experience with Twisted and
Tornado :-)
Regards
Antoine.
On Thu, 23 Apr 2015 09:30:30 +0200
Wolfgang Langner
Yury Selivanov wrote:
So how would we do await fut if await requires parentheses?
I've answered this with respect to PEP 3152 -- futures would
implement __cocall__, so you would write 'cocall fut()'.
I'm not sure what to say about PEP 492 here, because it
depends on exactly what a version of
Greg, how waiting for multiple cocalls should look and work?
In asyncio when I need to wait for two and more coroutines/futures I
use `asyncio.gather()`:
yield from gather(coro1(a1, a2), coro2(), fut3)
From my understanding to use cofunctions I must wrap it with costart call:
yield from
Yury Selivanov wrote:
So you would have to write 'await fut()'? This is non-intuitive.
That's because PEP 492 and its terminology encourage you
to think of 'await f()' as a two-step process: evaluate f(),
and then wait for the thing it returns to produce a
result.
PEP 3152 has a different
Paul Sokolovsky wrote:
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
You can also use a trampoline of some kind to
relay values back and forth between generators,
to get something symmetric.
Yes, that's of course how coroutine frameworks were done long before
yield from appeared and how
On Thu, Apr 23, 2015 at 3:10 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Andrew Svetlov wrote:
From my understanding to use cofunctions I must wrap it with costart call:
yield from gather(costart(coro1, a1, a2), costart(coro2), fut3)
There are other places in asyncio API those accept
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov andrew.svet...@gmail.com wrote:
[]
3.
async with and async for
Bead idea, we clutter the language even more and it is one more
thing every newbie
Hello,
On Thu, Apr 23, 2015 at 11:59 AM, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
On Thu, 23 Apr 2015 10:43:52 +0200
Wolfgang Langner tds333+py...@gmail.com wrote:
[]
Also ask why no one used type specifier, they are possible since
Python 3.0 ?
Because it is the wrong way for
On Thu, Apr 23, 2015 at 5:59 AM, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
On Thu, 23 Apr 2015 10:43:52 +0200
Wolfgang Langner tds333+py...@gmail.com wrote:
[]
Also ask why no one used type specifier, they are possible since
Python 3.0 ?
Because it is the wrong way for Python.
On Thu, Apr 23, 2015 at 3:27 PM, Wolfgang Langner
tds333+py...@gmail.com wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov andrew.svet...@gmail.com wrote:
[]
3.
async with and async for
Hello,
On Thu, 23 Apr 2015 14:48:58 +0200
Wolfgang Langner tds333+py...@gmail.com wrote:
Hello,
On Thu, Apr 23, 2015 at 11:59 AM, Paul Sokolovsky pmis...@gmail.com
wrote:
Hello,
On Thu, 23 Apr 2015 10:43:52 +0200
Wolfgang Langner tds333+py...@gmail.com wrote:
[]
Also ask
Andrew Svetlov wrote:
From my understanding to use cofunctions I must wrap it with costart call:
yield from gather(costart(coro1, a1, a2), costart(coro2), fut3)
There are other places in asyncio API those accept coroutines or
futures as parameters, not only Task() and async().
In a 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
Andrew Svetlov wrote:
But we already have asyncio and code based on asyncio coroutines.
To make it work I should always use costart() in places where asyncio
requires coroutine.
As I understand it, asyncio would require changes to
make it work seamlessly with PEP 492 as well, since
an object
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
Yury Selivanov writes:
To my eye 'async def name()', 'async with', 'async for' look
better than 'def async name()', 'with async' and 'for async'.
But that's highly subjective.
I'm with Barry on this one as far as looks go. (But count that as a
+0, since I'm just a literary critic, I don't
74 matches
Mail list logo
