
That'll be great, Nick. I look forward to your proposal. Alongside with you proposal, there might be capable guys who would like to contribute on the questions I raised in my initial mail on this list. This also might help Nick to hammer out a good proposal. On 10.07.2015 09:18, Nick Coghlan wrote:
On 10 July 2015 at 12:09, Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Jul 10, 2015 at 8:53 AM, Sven R. Kunze <srkunze@mail.de> 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 :)
That said, I think there may be a way to make the boundary between synchronous and asynchronous execution easier to conceptualise, so I'll put up a thread about that.
Cheers, Nick.