Asyncio -- delayed calculation

[Chris Kaynor]

On Wed, Nov 30, 2016 at 10:58 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Thu, Dec 1, 2016 at 5:54 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>> On 11/30/2016 7:53 AM, Chris Angelico wrote:
>>
>>> I also think that everyone should spend some time writing
>>> multithreaded code before switching to asyncio. It'll give you a
>>> better appreciation for what's going on.
>>
>>
>> I so disagree with this.  I have written almost no thread code but have
>> successfully written asyncio and async await code.  Perhaps this is because
>> I have written tkinter code, including scheduling code with root.after.  The
>> tk and asyncio event loops and scheduling are quite similar.
>
> Okay, so maybe not everyone needs threading, but certainly having a
> background in threading can help a lot. It _is_ possible to jump
> straight into asyncio, but if you haven't gotten your head around
> concurrency in other forms, you're going to get very much confused.
>
> Or maybe it's that the benefits of threaded programming can also be
> gained by working with event driven code. That's also possible.

I've dealt with multi-process (Python; some in C++ and C#),
multi-thread (Python, C++, C#, and other), and co-routine concurrency
(C#/Unity; I haven't used asyncio yet), and co-routine is by far the
simplest, as you don't have to deal with locking or race conditions in
general.

If you understand threading/multi-process programming, co-routines
will be easier to understand, as some of the aspects still apply.
Learning threading/process-based will be easier in some ways if you
know co-routine. In other ways, it will be harder as you'll have to
learn to consider locking and race conditions in coding.

I think in a venn-diagram of the complexity, co-routines would exist
in a circle contained by multi-process (only explicit shared memory
simplifies things, but there are still issues), which is inside a
circle by threading.