[Python-ideas] Concurrency Modules

Nikolaus Rath Nikolaus at rath.org
Sat Jul 11 17:00:34 CEST 2015


On Jul 10 2015, Nick Coghlan <ncoghlan-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> On 10 July 2015 at 12:09, Chris Angelico <rosuav-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
>> On Fri, Jul 10, 2015 at 8:53 AM, Sven R. Kunze <srkunze-7y4VAllY4QU at public.gmane.org> wrote:
>>> After discussing the whole topic and reading it up further, it became clear
>>> to me what's actually missing in Python. That is a definitive guide of
>>> why/when a certain concurrency module is supposed to be used
>>
>> I'm not sure how easy the decisions will be in all cases, but
>> certainly some broad guidelines would be awesome. (The exact analysis
>> of "when should I use threads and when should I use processes" is a
>> big enough one that there've been a few million blog posts on the
>> subject, and I doubt that asyncio will shrink that.) A basic summary
>> would be hugely helpful. "Here's four similar modules, and why they
>> all exist in the standard library."
>
> Q: Why are there four different modules
> A: Because they solve different problems
> Q: What are those problems?
> A: How long have you got?
>
> Choosing an appropriate concurrency model for a problem is one of the
> hardest tasks in software architecture design. The only way to make it
> appear simple is to focus in on a specific class of problems where
> there *is* a single clearly superior answer for that problem domain :)

But even just documenting this subset would already provide a lot of
improvement over the status quo.

If for each module there were an example of a problem that's clearly
best solved with this module rather than any of the others, that's a
perfectly good anwser to the question why they all exist. 


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«


More information about the Python-ideas mailing list