This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author srkunze
Recipients giampaolo.rodola, gvanrossum, ncoghlan, pitrou, r.david.murray, srkunze, vstinner, yselivanov
Date 2015-07-09.18:51:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> ... this sounds like it is encouraging staying ignorant.

True. However, I being ignorant about the complexity eventually led to the development of high-level languages like Python. Each time, a next generation simply asks the question: 'does it really need to be that complicated?' And each time, there is a solution. We will get there.

I have to admit, I do not stay ignorant because of convenience APIs but because I feel things made overly complicated.

I am not sure if we talk about asyncio anymore. I would say everything in Python regarding concurrency/parallelism needs to be put into perspective:

Modules I know MIGHT be interesting for me:
 - concurrent
 - threading
 - asyncio
 - multiprocessing

But I have no idea why/when to use which one.

AND more importantly, statements like "This class is almost compatible with concurrent.futures.Future." ( do not help. If it they are that compatible, why do we need both and when do I need which one? Or is this just another internal detail of implementation I can really be ignorant of?

From what I can tell right now (I read deeper into the topic, but always correct me if I am wrong), my perspective of the modules are now:

API of your application
1) either asynchronous/event loop/asyncio
2) or     synchronous/single event = start of program
the logic of the application
usage of other components
1) either 1 thread/imperative/line by line
2) or multithread/concurrent/parallel
3) or multiprocess/concurrent/parallel

My understanding is that asyncio is a way to implement the API of your application whereas concurrent/threading/multiprocessing provide means for more efficient execution of the underlying logic.

However, that cannot be entirely true, as I have already seen modules using asyncio to communication asynchronously with databases (to be honest that is what its name suggests async IO).

So, what? Seems like we can use asyncio also for communication with other components as well which my intuition held true as well. That is why I have trouble to understand why it is considered wrong to do the same with 'normal' functions (to me they are just other components).

AND it can also be the other way round: using concurrent/threading/multiprocessing for implementing the API of your application.
Date User Action Args
2015-07-09 18:51:28srkunzesetrecipients: + srkunze, gvanrossum, ncoghlan, pitrou, vstinner, giampaolo.rodola, r.david.murray, yselivanov
2015-07-09 18:51:28srkunzesetmessageid: <>
2015-07-09 18:51:28srkunzelinkissue24571 messages
2015-07-09 18:51:28srkunzecreate