Will multithreading make python less popular?

[andrew cooke]

Bruno Desthuilliers wrote:
> rushenaly at gmail.com a écrit :
> (snip)
>> And the story begins here. As i search on the net,  I have found that
>> because of the natural characteristics of python such as GIL, we are
>> not able to write multi threaded programs.
>
> I'm surprised no one here corrected that point yet, so here we go: yes,
> Python does support multithreading. The fact that threads won't be
> executed concurrently on a multicore machine (due to the GIL) is a
> different problem (cf Andrew Cooke's answer on this - and his advice to
> study Erlang if you want to do concurrent programming).

ah, sorry, i noticed this last night in another comment from rushenaly,
but forgot to say anything.

in case it's still not clear: you can have threads even on a single core. 
this is done by "time slicing" - some cpu time is given to one thread,
then to another.

exactly who does the slicing can vary.  in the case of a gui (which is
what i was about to explain last night then got distracted) it's quite
common for the gui library itself to do the scheduling of work.  so even
though the gui library uses a single thread, it can update several
windows, handle user input, etc "in parallel".  the next level is that the
language itself does the scheduling - that's what is commonly called
"threads".  finally the operating system can share things out (and that's
called processes).  but these are all basically the same thing, can happen
on a single core, and are not affected by the GIL (i have simplified
above; threads can also be a service that the operating system provides to
a language)

andrew