Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Steven D'Aprano
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 y

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Stephen J. Turnbull
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

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Yury Selivanov
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

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Greg Ewing
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

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Greg Ewing
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

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Greg Ewing
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

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Greg Ewing
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 n

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Chris Barker
On Wed, Apr 22, 2015 at 5:45 PM, Guido van Rossum 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 > simpler to just

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Greg Ewing
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

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Victor Stinner
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

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Łukasz Langa
> On Apr 23, 2015, at 10:51 AM, Barry Warsaw 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 __radd__ vs __add

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Yury Selivanov
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 ri

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Yury Selivanov
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 an

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread MRAB
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 bik

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Barry Warsaw
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"

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Yury Selivanov
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 t

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Barry Warsaw
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. Wh

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Yury Selivanov
Wolfgang, On 2015-04-23 12:58 PM, Wolfgang Langner wrote: On Thu, Apr 23, 2015 at 6:22 PM, Yury Selivanov wrote: Wolfgang, On 2015-04-23 12:12 PM, Wolfgang Langner wrote: On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov wrote: Hi Wolfgang, On 2015-04-23 8:27 AM, Wolfgang Langner wrote

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Ryan Gonzalez
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. > > >___

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Antoine Pitrou
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.

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Guido van Rossum
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 >

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Wolfgang Langner
On Thu, Apr 23, 2015 at 6:22 PM, Yury Selivanov wrote: > Wolfgang, > > > On 2015-04-23 12:12 PM, Wolfgang Langner wrote: > >> On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov >> wrote: >> >> Hi Wolfgang, >>> >>> On 2015-04-23 8:27 AM, Wolfgang Langner wrote: >>> >>> On Thu, Apr 23, 2015 at 12:3

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Yury Selivanov
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

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Yury Selivanov
Wolfgang, On 2015-04-23 12:12 PM, Wolfgang Langner wrote: On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov wrote: Hi Wolfgang, On 2015-04-23 8:27 AM, Wolfgang Langner wrote: On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky wrote: Hello, On Thu, 23 Apr 2015 12:18:51 +0300 Andrew Svetlo

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Wolfgang Langner
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov wrote: > Hi Wolfgang, > > On 2015-04-23 8:27 AM, Wolfgang Langner wrote: > >> On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky >> wrote: >> >> Hello, >>> >>> On Thu, 23 Apr 2015 12:18:51 +0300 >>> Andrew Svetlov wrote: >>> >>> [] >>> >>> 3. >>>

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Yury Selivanov
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

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Yury Selivanov
Hi Wolfgang, On 2015-04-23 11:57 AM, Wolfgang Langner wrote: On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov wrote: Hi Wolfgang, On 2015-04-23 8:27 AM, Wolfgang Langner wrote: On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky wrote: Hello, On Thu, 23 Apr 2015 12:18:51 +0300 Andrew Sve

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Wolfgang Langner
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov wrote: > Hi Wolfgang, > > On 2015-04-23 8:27 AM, Wolfgang Langner wrote: > >> On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky >> wrote: >> >> Hello, >>> >>> On Thu, 23 Apr 2015 12:18:51 +0300 >>> Andrew Svetlov wrote: >>> >>> [] >>> >>> 3. >>>

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Yury Selivanov
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

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Yury Selivanov
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

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Victor Stinner
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

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Yury Selivanov
Hi Wolfgang, On 2015-04-23 8:27 AM, Wolfgang Langner wrote: On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky wrote: Hello, On Thu, 23 Apr 2015 12:18:51 +0300 Andrew Svetlov wrote: [] 3. async with and async for Bead idea, we clutter the language even more and it is one more thing every

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Łukasz Langa
> 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

Re: [Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread andrew . svetlov
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,

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Paul Sokolovsky
Hello, On Thu, 23 Apr 2015 15:25:30 +0100 Harry Percival 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 mailto:pmis...@gmail.com _

Re: [Python-Dev] Task Request

2015-04-23 Thread Leonid Kokorev
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 > wrote: Hell

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Harry Percival
lol @ the fact that the type hints are breaking github's syntax highlighter :) On 23 April 2015 at 14:44, Paul Sokolovsky wrote: > Hello, > > On Thu, 23 Apr 2015 14:48:58 +0200 > Wolfgang Langner wrote: > > > Hello, > > > > On Thu, Apr 23, 2015 at 11:59 AM, Paul Sokolovsky > > wrote: > > > > >

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Daniel Holth
On Thu, Apr 23, 2015 at 9:55 AM, Paul Sokolovsky wrote: > Hello, > > On Thu, 23 Apr 2015 09:15:44 -0400 > Daniel Holth 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 exampl

Re: [Python-Dev] Task Request

2015-04-23 Thread Brett Cannon
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 wrote: > Hello. > My name is Leonid. I'm very interested in Python programming language. > I'm sending this le

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Paul Sokolovsky
Hello, On Thu, 23 Apr 2015 09:15:44 -0400 Daniel Holth 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 - MyPy

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Paul Sokolovsky
Hello, On Thu, 23 Apr 2015 14:48:58 +0200 Wolfgang Langner wrote: > Hello, > > On Thu, Apr 23, 2015 at 11:59 AM, Paul Sokolovsky > wrote: > > > Hello, > > > > On Thu, 23 Apr 2015 10:43:52 +0200 > > Wolfgang Langner wrote: > > > > [] > > > > > Also ask why no one used type specifier, they are

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Andrew Svetlov
On Thu, Apr 23, 2015 at 3:27 PM, Wolfgang Langner wrote: > > > On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky wrote: >> >> Hello, >> >> On Thu, 23 Apr 2015 12:18:51 +0300 >> Andrew Svetlov wrote: >> >> [] >> >> > > 3. >> > > async with and async for >> > > Bead idea, we clutter the language e

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Daniel Holth
On Thu, Apr 23, 2015 at 5:59 AM, Paul Sokolovsky wrote: > Hello, > > On Thu, 23 Apr 2015 10:43:52 +0200 > Wolfgang Langner 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 pe

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Paul Sokolovsky
Hello, On Thu, 23 Apr 2015 12:18:51 +0300 Andrew Svetlov 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' framework lived

[Python-Dev] PEP 3152 and yield from Future()

2015-04-23 Thread Victor Stinner
(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

[Python-Dev] Task Request

2015-04-23 Thread Leonid Kokorev
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 ld

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Paul Sokolovsky
Hello, On Thu, 23 Apr 2015 20:39:51 +1200 Greg Ewing 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 > > continuation-passi

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Florian Bruhin
* Wolfgang Langner [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 have to specify typ

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Paul Sokolovsky
Hello, On Thu, 23 Apr 2015 10:43:52 +0200 Wolfgang Langner 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 - MyPy, MicroPython, e

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Yury Selivanov
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 https://mail.python.org/mailman/listinfo/python-d

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Yury Selivanov
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, n

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Wolfgang Langner
Hello, On Thu, Apr 23, 2015 at 11:59 AM, Paul Sokolovsky wrote: > Hello, > > On Thu, 23 Apr 2015 10:43:52 +0200 > Wolfgang Langner 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 exam

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Wolfgang Langner
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky wrote: > Hello, > > On Thu, 23 Apr 2015 12:18:51 +0300 > Andrew Svetlov 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. > > > f

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Andrew Svetlov
On Thu, Apr 23, 2015 at 3:10 PM, 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 >

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Greg Ewing
Paul Sokolovsky wrote: Greg Ewing 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 Trollius works now. No, what

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Greg Ewing
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 a

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Greg Ewing
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 ph

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Andrew Svetlov
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 gather

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Greg Ewing
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

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Andrew Svetlov
On Thu, Apr 23, 2015 at 10: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 fro

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Greg Ewing
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 o

Re: [Python-Dev] Questionable TCP server example

2015-04-23 Thread Antoine Pitrou
On Thu, 23 Apr 2015 09:21:11 +0200 Andrea Griffini 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 think so

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Antoine Pitrou
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 wrote:

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Wolfgang Langner
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 writte

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Greg Ewing
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 and

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Greg Ewing
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 __

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Greg Ewing
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 "cofunctio

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Greg Ewing
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

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Wolfgang Langner
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 mi

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

2015-04-23 Thread Terry Reedy
On 4/22/2015 8:45 PM, Guido van Rossum wrote: On Wed, Apr 22, 2015 at 2:38 PM, Chris Barker mailto:chris.bar...@noaa.gov>> wrote: On Tue, Apr 21, 2015 at 11:32 PM, Terry Reedy mailto:tjre...@udel.edu>> wrote: I was just thinking today that for this, typing needs a subtract

[Python-Dev] Questionable TCP server example

2015-04-23 Thread Andrea Griffini
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 read

Re: [Python-Dev] async/await in Python; v2

2015-04-23 Thread Greg Ewing
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 Python-Dev@python.org