decorators vs GIL

[G. S. Hayes]

mudd at vex.net wrote in message news:<mailman.1372.1092017928.5135.python-list at python.org>...

> > That's not to say there aren't limited problem domains where threads

> > are the right answer, but as a general construct they're wildly

> > overused.  I'm frankly glad that Python doesn't encourage more of the

> > same.

> >

> 

> Is there anything else that Python doesn't do well that we should appreciate?



That wasn't really the point; the point was more to argue against the
viewpoint that work on language features like list comprehensions or
decorators is somehow less important than working on removing the GIL.
 Obviously in an ideal world you could implement every idea that came
along, but in the real world developers tend to work on problems that
affect them--and if you have a bunch of developers who rarely run into
problems with the GIL (because they're not often abusing threads) then
it's just not going to be a very high priority.  Rightly so, IMO,
since it only affects a very small percentage of well-designed
programs, so putting work into bigger problem areas (especially any
language features that genuinely improve development speed and
readability) gets a much higher payoff.



I wouldn't be against removing the GIL if an approach was found that
didn't adversely affect the common case; naive approaches to
fine-grained locking are often really bad for general case behavior,
but there are approaches that can mitigate this.  But I would be
against lobbying core language developers to take time off of other
projects to work on this one; it's definitely more of a "scratch an
itch" type problem` that can wait until someone feels motivated to do
it than a "suck it up because the community needs it" kind of thing.