[Python-ideas] A concurrency survey of sorts

[Mike Meyer]

On Fri, Nov 4, 2011 at 12:09 PM, C. Titus Brown <ctb at msu.edu> wrote:
> On Fri, Nov 04, 2011 at 12:02:06PM -0700, Mike Meyer wrote:
>> On Fri, Nov 4, 2011 at 11:42 AM, Weeble <clockworksaint at gmail.com> wrote:
>> > I just want to be sure - the idea of removing the threading module
>> > sounds ludicrous. It's not getting serious consideration, is it?
>>
>> Removing  the threading module - as part of a change that includes
>> providing some other concurrent processing facility - seems like a
>> reasonable enough idea that I'll be including it in the sequel.
>> Rewriting it to use those facilities might be reasonable for backwards
>> compatibility, but the new facilities should have enough advantages
>> that new code would just use them.
>
> I obviously haven't been paying enough attention to this conversation,
> because this strikes me as a horrible idea.  In particular, I write
> C extensions that release the GIL and scale just fine across multiple
> processors.  Is the idea to force those kind of applications to use
> a new communications model?

That's one of the ideas. The goal is to get the Python processor to
help locate concurrency bugs. Since the threading module
communications model is "everything is shared by default", I'm pretty
sure it's going to break code that depends on it. But that's why it's
a proposal for Python 4 or something even further away.

    <mike