On Wed, Nov 30, 2016 at 10:58 AM, Chris Angelico <ros...@gmail.com> wrote: > On Thu, Dec 1, 2016 at 5:54 AM, Terry Reedy <tjre...@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. -- https://mail.python.org/mailman/listinfo/python-list
