decorators vs GIL

[G. S. Hayes]

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

> What really hurts is that I can't honestly tell Java programmers that

> Python  is a slam dunk compared to Java & the JVM.  Java has no GIL,



Java has drunk the threads Kool-Aid, and Java programmers are very
likely to be thread-crazy because of the lack of a select equivalent
(until recently) and the lack of good access to processes via fork or
similar.  Luckily, it's usually pretty easy to convince people of the
benefits of NOT overusing threads once they've made that mistake once.



I honestly think a big reason the GIL isn't a major issue to most
Pythonistas is because they tend to know that there's a better way to
approach most problems than using threads.



> Isn't that like saying, I avoid programming in general because it's

> error-prone?  I don't follow.



Not really.  You need to program to get things done, but presumably
you leverage all the work that's been done over the past 40+ years to
make that an easier, less error-prone task.  It's like saying you
shouldn't program in assembly because it's error prone; sure, there
are some cases where it makes sense, but in general it's not a great
idea.



Threads are error-prone because they intentionally circumvent the
years of OS work that went into getting protected memory for us in the
first place.  Even for tasks that aren't neatly divided into an event
loop, processes are available for parallel execution.  99% of the time
they're a better choice _except_ that two of the most dominant
programming platforms out there don't have a good (efficient and
featureful) implementation (Java and Windows).  It's absolutely insane
that many Windows programmers believe that to use parallel processing
requires you throw out memory protection; the two concepts are very
distantly related.  The decision to use threads vs. processes ought to
come down to whether you want to share ALL memory (and deal with the
locking and reentrancy issues that come along with that choice) or
only a specified subset of memory.  When you view it from that
perspective, threads are only rarely the right choice.



Indeed, in all the years that I've been writing code I've never once
found a problem where I felt threads were the right approach--and that
includes work on high-performance servers with thousands of concurrent
users, large-scale data visualization applications that depend on the
results of many parallel searches, and realtime audio processing
applications with non-realtime visualization and UI components. 
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.