[Python-ideas] Python 3000 TIOBE -3%

[C. Titus Brown]

On Thu, Feb 09, 2012 at 08:42:40PM +0100, Masklinn wrote:
> On 2012-02-09, at 20:36 , C. Titus Brown wrote:
> > On Fri, Feb 10, 2012 at 03:19:36AM +0800, Matt Joiner wrote:
> >>> The GIL annoys those who have learned to expect threading.Thread for CPU
> >>> bound concurrency in advance -- which typically means prior experience with
> >>> Java. Python threads are fine for their intended use -- e.g. I/O and
> >>> background tasks in a GUI.
> >> 
> >> Even for that purpose they're too heavy. The GIL conflicts, and
> >> boilerplate overhead spawning threads is obscene for more than trivial
> >> cases.
> > 
> > The GIL is almost entirely a PR issue.  In actual practice, it is so great
> > (simple, straightforward, functional) I believe that it is a sign of Guido's
> > time machine-enabled foresight.
> 
> I'm not sure dabeaz would agree with you if he intervened in the discussion.

Are we scheduling interventions for me now?  'cause there's a lot of people
who want to jump in that queue :)

dabeaz understands this stuff at a deeper level than me, which is often a
handicap in these kinds of discussions, IMO.  (He's also said that he prefers
message passing to threading.)  The point is that in terms of actually making
my own libraries and parallelizing code, the GIL has been very straightforward,
cross platform, and quite simple for understanding the consequences of a fairly
wide range of multithreading models.  Most people want to go do inappropriately
complex things ("ooh! threads! shiny!") with threads and then fail to write
robust code or understand the scaling of their code; I think the GIL does a
fine job of blocking the simplest stupidities.

Anyway, I love the GIL myself, although I think there is a great opportunity
for a richer & more usable mid-level C API for both thread states and
interpreters.

cheers,
--titus
-- 
C. Titus Brown, ctb at msu.edu