Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #103074 > unrolled thread

How the heck does async/await work in Python 3.5

Back to article view | Back to comp.lang.python

Contents

  How the heck does async/await work in Python 3.5 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-02-17 22:08 +0000
    Re: How the heck does async/await work in Python 3.5 Steven D'Aprano <steve@pearwood.info> - 2016-02-20 13:36 +1100
      Re: How the heck does async/await work in Python 3.5 Rustom Mody <rustompmody@gmail.com> - 2016-02-19 21:24 -0800
        Re: How the heck does async/await work in Python 3.5 Rustom Mody <rustompmody@gmail.com> - 2016-02-19 21:34 -0800
          Re: How the heck does async/await work in Python 3.5 Paul Rubin <no.email@nospam.invalid> - 2016-02-19 22:44 -0800
            Re: How the heck does async/await work in Python 3.5 Steven D'Aprano <steve@pearwood.info> - 2016-02-21 18:17 +1100
              Re: How the heck does async/await work in Python 3.5 Paul Rubin <no.email@nospam.invalid> - 2016-02-20 23:34 -0800
        Re: How the heck does async/await work in Python 3.5 Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-20 00:48 -0700
        Re: How the heck does async/await work in Python 3.5 Chris Angelico <rosuav@gmail.com> - 2016-02-20 18:57 +1100
        Re: How the heck does async/await work in Python 3.5 Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-20 01:14 -0700
        Re: How the heck does async/await work in Python 3.5 Chris Angelico <rosuav@gmail.com> - 2016-02-20 19:49 +1100
        Re: How the heck does async/await work in Python 3.5 Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-20 02:11 -0700
        Re: How the heck does async/await work in Python 3.5 Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-20 02:21 -0700
      Re: How the heck does async/await work in Python 3.5 Christian Gollwitzer <auriocus@gmx.de> - 2016-02-20 07:53 +0100
        Re: How the heck does async/await work in Python 3.5 "Sven R. Kunze" <srkunze@mail.de> - 2016-02-22 23:16 +0100
        Re: How the heck does async/await work in Python 3.5 Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-22 17:48 -0700
        Re: How the heck does async/await work in Python 3.5 "Sven R. Kunze" <srkunze@mail.de> - 2016-02-23 17:50 +0100
        Re: How the heck does async/await work in Python 3.5 Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-23 10:37 -0700
        Re: How the heck does async/await work in Python 3.5 "Sven R. Kunze" <srkunze@mail.de> - 2016-02-23 20:42 +0100
        Re: How the heck does async/await work in Python 3.5 "Sven R. Kunze" <srkunze@mail.de> - 2016-02-23 22:05 +0100
        Re: [Python-ideas] How the heck does async/await work in Python 3.5 "Joao S. O. Bueno" <jsbueno@python.org.br> - 2016-02-23 18:25 -0300
        Re: [Python-ideas] How the heck does async/await work in Python 3.5 Paul Moore <p.f.moore@gmail.com> - 2016-02-24 09:59 +0000
        Re: [Python-ideas] How the heck does async/await work in Python 3.5 Victor Stinner <victor.stinner@gmail.com> - 2016-02-24 11:01 +0100
        Re: [Python-ideas] How the heck does async/await work in Python 3.5 王珺 <wjun77@gmail.com> - 2016-02-24 18:40 +0800
          Re: [Python-ideas] How the heck does async/await work in Python 3.5 Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-02-25 10:00 +1300
            Re: [Python-ideas] How the heck does async/await work in Python 3.5 王珺 <wjun77@gmail.com> - 2016-02-25 08:40 +0800
            Re: [Python-ideas] How the heck does async/await work in Python 3.5 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-24 20:37 -0500
        Re: [Python-ideas] How the heck does async/await work in Python 3.5 Tem Pl <rtempl31@gmail.com> - 2016-02-24 06:39 -0800
          Re: [Python-ideas] How the heck does async/await work in Python 3.5 Marko Rauhamaa <marko@pacujo.net> - 2016-02-24 17:23 +0200
            Re: [Python-ideas] How the heck does async/await work in Python 3.5 Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-24 08:41 -0700
              Re: [Python-ideas] How the heck does async/await work in Python 3.5 Marko Rauhamaa <marko@pacujo.net> - 2016-02-24 18:13 +0200
                Re: [Python-ideas] How the heck does async/await work in Python 3.5 Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-24 09:47 -0700

Page 1 of 2  [1] 2  Next page →

#103074 — How the heck does async/await work in Python 3.5

Seeing there is a lot of interest in asyncio recently I figured people 
might be interested in this 
http://www.snarky.ca/how-the-heck-does-async-await-work-in-python-3-5

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [next] | [standalone]

#103233

On Thu, 18 Feb 2016 09:08 am, Mark Lawrence wrote:

> Seeing there is a lot of interest in asyncio recently I figured people
> might be interested in this
> http://www.snarky.ca/how-the-heck-does-async-await-work-in-python-3-5


Thanks for the link, but I'm now no wiser than I was before :-(

Can somebody explain Brett's explanation?




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#103237

On Saturday, February 20, 2016 at 8:07:03 AM UTC+5:30, Steven D'Aprano wrote:
> On Thu, 18 Feb 2016 09:08 am, Mark Lawrence wrote:
> 
> > Seeing there is a lot of interest in asyncio recently I figured people
> > might be interested in this
> > http://www.snarky.ca/how-the-heck-does-async-await-work-in-python-3-5
> 
> 
> Thanks for the link, but I'm now no wiser than I was before :-(
> 
> Can somebody explain Brett's explanation?

Does "C++" light a bulb? <wink>

Less snarkily looks like a series of bolt-ons after bolt-ons

IMHO Guido's (otherwise) uncannily sound intuitions have been wrong right from
2001 when he overloaded def for generators.
And after that its been slippery-slope down: reusing generator-yield (statement)
for coroutine-yield (expression)
Most recently choosing these async-await keywords instead of the more symmetric 
suggestions of Greg Ewing

PS. Will be off email/net for about a week

[toc] | [prev] | [next] | [standalone]

#103238

On Saturday, February 20, 2016 at 10:55:02 AM UTC+5:30, Rustom Mody wrote:
> On Saturday, February 20, 2016 at 8:07:03 AM UTC+5:30, Steven D'Aprano wrote:
> > On Thu, 18 Feb 2016 09:08 am, Mark Lawrence wrote:
> > 
> > > Seeing there is a lot of interest in asyncio recently I figured people
> > > might be interested in this
> > > http://www.snarky.ca/how-the-heck-does-async-await-work-in-python-3-5
> > 
> > 
> > Thanks for the link, but I'm now no wiser than I was before :-(
> > 
> > Can somebody explain Brett's explanation?
> 
> Does "C++" light a bulb? <wink>
> 
> Less snarkily looks like a series of bolt-ons after bolt-ons
> 
> IMHO Guido's (otherwise) uncannily sound intuitions have been wrong right from
> 2001 when he overloaded def for generators.
> And after that its been slippery-slope down: reusing generator-yield (statement)
> for coroutine-yield (expression)
> Most recently choosing these async-await keywords instead of the more symmetric 
> suggestions of Greg Ewing

Forgot the probably most important: Not merging stackless into CPython

[toc] | [prev] | [next] | [standalone]

#103239

Rustom Mody <rustompmody@gmail.com> writes:
> Forgot the probably most important: Not merging stackless into CPython

I thought there was some serious technical obstacle to that.

Where can I find Greg Ewing's suggestions about Python coroutines?  The
async/await stuff seems ok on the surface.

I liked the Lua paper about coroutines:

  http://www.inf.puc-rio.br/~roberto/docs/corosblp.pdf

it has a fair amount of historical info, comparison of implementation
techniques, etc.

But frankly the stuff I'm seeing in this thread makes me sad for Python.
It's an impossible dream but it would be awesome to have Erlang-like
communicating microtasks in Python.

[toc] | [prev] | [next] | [standalone]

#103282

On Sat, 20 Feb 2016 05:44 pm, Paul Rubin wrote:

> But frankly the stuff I'm seeing in this thread makes me sad for Python.
> It's an impossible dream but it would be awesome to have Erlang-like
> communicating microtasks in Python.

"But frankly the stuff I'm seeing in this thread makes me sad for *literally
every programming language in existence except for Erlang and maybe one or
two others*, which altogether about six people use in total..."

:-)





-- 
Steven

[toc] | [prev] | [next] | [standalone]

#103284

Steven D'Aprano <steve@pearwood.info> writes:
> "But frankly the stuff I'm seeing in this thread makes me sad for
> *literally every programming language in existence except for Erlang
> and maybe one or two others*, which altogether about six people use in
> total..."

Erlang microtasks are more a matter of the runtime environment than the
language.  It might be possible to have something like it in PyPy.

Other languages typically do concurrency with something like:

  1. threads - various hazards that can be avoided if you're careful
  2. callback chaining like in node.js - gets messy if the program
     is complicated, but conceptually simple
  3. explicit state machines with something like libevent in C --
     same as #2, simple but tedious
  4. lightweight threads/tasks like in GHC and Erlang -- very nice though
     requires a sophisticated runtime system
  5. cooperative multasking (small RTOS's, Forth, etc): simple, but
     apparently bug-prone when the program gets complicated

Python's async stuff seems to combine various of the above approaches
and (while I'm not saying it's objectively bad) the experiences I've had
with it so far have been confusing and unpleasant.  I do want to put
some effort into understanding asyncio, but so far threads have worked
ok for me.

OK Web Server (uses a separate C++ process for each page on the site)
looked straightforward and fast, though makes some architectural
impositions.

http://seastar-project.org/ seems interesting but I don't understand it
at the moment.

[toc] | [prev] | [next] | [standalone]

#103244

On Fri, Feb 19, 2016 at 10:24 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> Less snarkily looks like a series of bolt-ons after bolt-ons
>
> IMHO Guido's (otherwise) uncannily sound intuitions have been wrong right from
> 2001 when he overloaded def for generators.
> And after that its been slippery-slope down: reusing generator-yield (statement)
> for coroutine-yield (expression)
> Most recently choosing these async-await keywords instead of the more symmetric
> suggestions of Greg Ewing

Two out of three of those are fine. IMO generators should have
required a separate keyword to distinguish them from ordinary
functions, but it's a minor complaint and they're otherwise a great
addition to the language.

I do think it's pretty clear at this point though that PEP 342 was a
mistake. We should never have introduced generator-based coroutines;
it's an abstraction with too much leakage. It doesn't make sense that
generator-based coroutines implement the iterator protocol, because
there's no reason to ever try to iterate over them. It also doesn't
make sense to ever iterate over a Future, and yet asyncio Futures,
which aren't even coroutines, are nevertheless *forced* to be iterable
just because that's how coroutines work. Otherwise you couldn't "yield
from" a Future.

As another point that happens to be fresh in my mind, awaiting a
Future on which an exception gets set is supposed to propagate the
exception. I recently found that this breaks if the exception in
question happens to be StopIteration (granted not one that should
generally be allowed to propagate anyway, but that's a separate
discussion) for the simple reason that raising StopIteration in a
generator is equivalent to returning None. The awaiting coroutine thus
gets a non-exceptional result of None rather than the expected
exception. The irritating thing to me is that this even plagues PEP
492 coroutines using "await" rather than "yield from", because the two
are basically the same under the covers. The former gets an iterator
by calling __await__ instead of __iter__, but it's still implemented
using an iterator. If you look at the asyncio.Future implementation,
__await__ is actually just a synonym of the __iter__ method.

My hope is that someday we can get rid of PEP 342 coroutines entirely.
Then maybe we can get a coroutine implementation that's actually sane.
PEP 492 with async/await and non-iterable semantics is a step in the
right direction, but ultimately I think we also need an underlying
implementation that *isn't* fundamentally based on iteration.

[toc] | [prev] | [next] | [standalone]

#103246

On Sat, Feb 20, 2016 at 6:48 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> As another point that happens to be fresh in my mind, awaiting a
> Future on which an exception gets set is supposed to propagate the
> exception. I recently found that this breaks if the exception in
> question happens to be StopIteration (granted not one that should
> generally be allowed to propagate anyway, but that's a separate
> discussion) for the simple reason that raising StopIteration in a
> generator is equivalent to returning None.

Solved by PEP 479. Use "from __future__ import generator_stop" to save
yourself the pain.

ChrisA

[toc] | [prev] | [next] | [standalone]

#103249

On Sat, Feb 20, 2016 at 12:57 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Feb 20, 2016 at 6:48 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> As another point that happens to be fresh in my mind, awaiting a
>> Future on which an exception gets set is supposed to propagate the
>> exception. I recently found that this breaks if the exception in
>> question happens to be StopIteration (granted not one that should
>> generally be allowed to propagate anyway, but that's a separate
>> discussion) for the simple reason that raising StopIteration in a
>> generator is equivalent to returning None.
>
> Solved by PEP 479. Use "from __future__ import generator_stop" to save
> yourself the pain.

Nope.

py> from __future__ import generator_stop
py> import asyncio
py> async def test_coro():
...     fut = asyncio.Future()
...     fut.set_exception(StopIteration())
...     print('received %r' % await fut)
...
py> list(test_coro().__await__())
received None
[]

I think because __future__ imports are per-file, and
asyncio.Future.__iter__ is defined in a file outside my control that
doesn't have the __future__ import.

I suppose that when the generator_stop behavior becomes standard then
it will work, but still that will just cause a RuntimeError to
propagate instead of the desired StopIteration.

It's not really that big a deal since there is a code smell to it, but
it's surprising since intuitively StopIteration should have no special
meaning to a PEP 492 coroutine (it's not an iterator, wink wink, nudge
nudge), and the thing being awaited is a Future, which also doesn't
intuitively look like an iterator. Note that if you just call
Future.result(), then the exception propagates as expected; it's just
awaiting it that doesn't work.

[toc] | [prev] | [next] | [standalone]

#103254

On Sat, Feb 20, 2016 at 7:14 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Sat, Feb 20, 2016 at 12:57 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> On Sat, Feb 20, 2016 at 6:48 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>> As another point that happens to be fresh in my mind, awaiting a
>>> Future on which an exception gets set is supposed to propagate the
>>> exception. I recently found that this breaks if the exception in
>>> question happens to be StopIteration (granted not one that should
>>> generally be allowed to propagate anyway, but that's a separate
>>> discussion) for the simple reason that raising StopIteration in a
>>> generator is equivalent to returning None.
>>
>> Solved by PEP 479. Use "from __future__ import generator_stop" to save
>> yourself the pain.
>
> Nope.
>
> py> from __future__ import generator_stop
> py> import asyncio
> py> async def test_coro():
> ...     fut = asyncio.Future()
> ...     fut.set_exception(StopIteration())
> ...     print('received %r' % await fut)
> ...
> py> list(test_coro().__await__())
> received None
> []
>
> I think because __future__ imports are per-file, and
> asyncio.Future.__iter__ is defined in a file outside my control that
> doesn't have the __future__ import.

You need the future directive in the file that defines the function
that raises, so I guess you'd need to apply that to an asyncio call.
The tricky bit here is that it's a backward compatibility change, but
since asyncio is flagged provisional, I suspect the future directive
could be added (anyone who's depending on
set_exception(StopIteration()) to terminate without an exception will
have to change code).

Actually, that mightn't be a bad thing. Maybe raise that as a tracker
issue? I just tested, and slapping "from __future__ import
generator_stop" at the top of Lib/asyncio/futures.py causes your
example to raise an exception instead of returning None, and doesn't
seem to break the test suite.

> I suppose that when the generator_stop behavior becomes standard then
> it will work, but still that will just cause a RuntimeError to
> propagate instead of the desired StopIteration.

That then becomes a pretty minor wart, on par with hash() never
returning -1 (which I came across recently, but only by snooping the
source) - it'll hack it to -2 instead, because -1 is used as an error
signal. In the same way, StopIteration is special-cased as a return
signal (because there needs to be _some_ mechanism for distinguishing
between yield and raise and return; normally, the difference between
"has a value to return" and "has no value to return" is indicated by
raising in the latter case, but now we need even more
distinguishments), it can't actually be raised per se. Since the
exception chains, you can't get confused.

> It's not really that big a deal since there is a code smell to it, but
> it's surprising since intuitively StopIteration should have no special
> meaning to a PEP 492 coroutine (it's not an iterator, wink wink, nudge
> nudge), and the thing being awaited is a Future, which also doesn't
> intuitively look like an iterator. Note that if you just call
> Future.result(), then the exception propagates as expected; it's just
> awaiting it that doesn't work.

Definitely seems like it should be fixed, then; the current behaviour
is that Future.result() raises RuntimeError if you raise
StopIteration, so having await do the same would make sense.

ChrisA

[toc] | [prev] | [next] | [standalone]

#103259

On Sat, Feb 20, 2016 at 1:49 AM, Chris Angelico <rosuav@gmail.com> wrote:
> Definitely seems like it should be fixed, then; the current behaviour
> is that Future.result() raises RuntimeError if you raise
> StopIteration, so having await do the same would make sense.

Future.result() itself simply raises the StopIteration. If you call it
inside a coroutine (which seems odd -- why not await it?) then it's
the coroutine that reraises the StopIteration as RuntimeError. The
__future__ import doesn't even seem to be needed in this case.

[toc] | [prev] | [next] | [standalone]

#103261

On Sat, Feb 20, 2016 at 1:49 AM, Chris Angelico <rosuav@gmail.com> wrote:
> Actually, that mightn't be a bad thing. Maybe raise that as a tracker
> issue? I just tested, and slapping "from __future__ import
> generator_stop" at the top of Lib/asyncio/futures.py causes your
> example to raise an exception instead of returning None, and doesn't
> seem to break the test suite.

I added your suggestion to the existing http://bugs.python.org/issue26221.

[toc] | [prev] | [next] | [standalone]

#103240

Am 20.02.16 um 03:36 schrieb Steven D'Aprano:
> On Thu, 18 Feb 2016 09:08 am, Mark Lawrence wrote:
>
>> Seeing there is a lot of interest in asyncio recently I figured people
>> might be interested in this
>> http://www.snarky.ca/how-the-heck-does-async-await-work-in-python-3-5
>
>
> Thanks for the link, but I'm now no wiser than I was before :-(
>
> Can somebody explain Brett's explanation?

If you have difficulties wit hthe overall concept, and if you are open 
to discussions in another language, take a look at this video:

https://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-39-await-co-routines

MS has added coroutine support with very similar syntax to VC++ 
recently, and the developer tries to explain it to the "stackful" 
programmers.

	Christian

[toc] | [prev] | [next] | [standalone]

#103366

On 20.02.2016 07:53, Christian Gollwitzer wrote:
> If you have difficulties wit hthe overall concept, and if you are open 
> to discussions in another language, take a look at this video:
>
> https://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-39-await-co-routines 
>
>
> MS has added coroutine support with very similar syntax to VC++ 
> recently, and the developer tries to explain it to the "stackful" 
> programmers.

Thanks, Christian. Very informative video.

Is something like shown in 12:50 ( cout << tcp_reader(1000).get() ) 
possible with asyncio? (tcp_reader would be async def)


Best,
Sven

[toc] | [prev] | [next] | [standalone]

#103385

On Mon, Feb 22, 2016 at 3:16 PM, Sven R. Kunze <srkunze@mail.de> wrote:
> Is something like shown in 12:50 ( cout << tcp_reader(1000).get() ) possible
> with asyncio? (tcp_reader would be async def)

loop = asyncio.get_event_loop()
print(loop.run_until_complete(tcp_reader(1000)))

[toc] | [prev] | [next] | [standalone]

#103406

On 23.02.2016 01:48, Ian Kelly wrote:
> On Mon, Feb 22, 2016 at 3:16 PM, Sven R. Kunze <srkunze@mail.de> wrote:
>> Is something like shown in 12:50 ( cout << tcp_reader(1000).get() ) possible
>> with asyncio? (tcp_reader would be async def)
> loop = asyncio.get_event_loop()
> print(loop.run_until_complete(tcp_reader(1000)))

I see. Thanks. :)

How come that Python (compared to C++) needs much more boilerplate to 
use async programming? Historically, it was the other way round.

Best,
Sven

[toc] | [prev] | [next] | [standalone]

#103410

On Tue, Feb 23, 2016 at 9:50 AM, Sven R. Kunze <srkunze@mail.de> wrote:
> On 23.02.2016 01:48, Ian Kelly wrote:
>>
>> On Mon, Feb 22, 2016 at 3:16 PM, Sven R. Kunze <srkunze@mail.de> wrote:
>>>
>>> Is something like shown in 12:50 ( cout << tcp_reader(1000).get() )
>>> possible
>>> with asyncio? (tcp_reader would be async def)
>>
>> loop = asyncio.get_event_loop()
>> print(loop.run_until_complete(tcp_reader(1000)))
>
>
> I see. Thanks. :)
>
> How come that Python (compared to C++) needs much more boilerplate to use
> async programming? Historically, it was the other way round.

It's not entirely clear to me what the C++ is actually doing. With
Python we have an explicit event loop that has to be started to manage
resuming the coroutines. Since it's explicit, you could easily drop in
a different event loop, such as Tornado or curio, if desired. If your
coroutine never awaits anything that isn't already done then
technically you don't need an event loop, but at that point you might
as well be using ordinary functions.

The C++ on the other hand seems to be doing something implicit at the
compiler level to make everything happen automatically inside the
future.get() call, but I don't know what that is.

You could wrap up the boilerplate in Python if you like:

def get(coro, loop=None):
    if loop is None:
        loop = asyncio.get_event_loop()
    return loop.run_until_complete(coro)

print(get(tcp_reader(1000)))

[toc] | [prev] | [next] | [standalone]

#103415

On 23.02.2016 18:37, Ian Kelly wrote:
> It's not entirely clear to me what the C++ is actually doing. With
> Python we have an explicit event loop that has to be started to manage
> resuming the coroutines. Since it's explicit, you could easily drop in
> a different event loop, such as Tornado or curio, if desired. If your
> coroutine never awaits anything that isn't already done then
> technically you don't need an event loop, but at that point you might
> as well be using ordinary functions.

I don't think taking the shortcut to ordinary functions will work on the 
big scale.

I certainly agree that asynchronous operations can/should? be the very 
core of everything (files, sockets, timers, etc.); just as Microsoft is 
pushing with their Windows API. Chaining async ops together just works 
now with async/await in Python as well. However, in the end of the 
chaining there'll always be synchronous code that e.g. initializes the 
event loop. Real world code works the same.

Imagine, in some near/distant future, Python might have all its core 
components (like reading a file, etc. etc.) converted to async. It would 
be great for many larger applications if there one could introduce async 
gently. So, laying out an async foundation (the building blocks) but the 
wiring synchronous operations still work as they should. Once, the team 
decides they want to leverage the async potential in their code (as the 
building blocks COULD be executed concurrently), they will then be able 
to replace the synchronous wires with an event loop.

So, I see quite some potential here.

> The C++ on the other hand seems to be doing something implicit at the
> compiler level to make everything happen automatically inside the
> future.get() call, but I don't know what that is.
>
> You could wrap up the boilerplate in Python if you like:
>
> def get(coro, loop=None):
>      if loop is None:
>          loop = asyncio.get_event_loop()
>      return loop.run_until_complete(coro)
>
> print(get(tcp_reader(1000)))

As usual. :)

Best,
Sven

[toc] | [prev] | [next] | [standalone]

#103416

On 20.02.2016 07:53, Christian Gollwitzer wrote:
> If you have difficulties wit hthe overall concept, and if you are open 
> to discussions in another language, take a look at this video:
>
> https://channel9.msdn.com/Shows/C9-GoingNative/GoingNative-39-await-co-routines 
>
>
> MS has added coroutine support with very similar syntax to VC++ 
> recently, and the developer tries to explain it to the "stackful" 
> programmers.

Because of this thread, I finally finished an older post collecting 
valuable insights from last year discussions regarding concurrency 
modules available in Python: 
http://srkunze.blogspot.com/2016/02/concurrency-in-python.html It 
appears to me that it would fit here well.

@python-ideas
Back then, the old thread ("Concurrency Modules") was like basically 
meant to result in something useful. I hope the post covers the essence 
of the discussion.
Some even suggested putting the table into the Python docs. I am unaware 
of the formal procedure here but I would be glad if somebody could point 
be at the right direction if that the survey table is wanted in the docs.

Best,
Sven

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web