Simple threads (was Re: listing threads?)

[Aahz Maruch]

In article <uadttot9v.fsf at ctwd0143.fitlinxx.com>,
David Bolen  <db3l at fitlinxx.com> wrote:
>aahz at panix.com (Aahz Maruch) writes:
>>
>> DON'T DO THAT.  I'm serious.  You really do NOT want to use
>> threading.enumerate(); you'll only confuse yourself.  I've pointed you
>> at my web page on threading; is there some reason you haven't read it,
>> or is there something you don't understand?
>
>I wouldn't go all that far.  Clearly you have to understand the nature
>of the snapshot that threading.enumerate() returns with respect to the
>asychronous nature of threads (which of course is what was confusing
>the OP, since the example had a thread that barely got off the ground
>before exiting).
>
>But I don't see that enumerate() is in and of itself a bad method,
>when used properly - certainly not something to warrant such a
>sweeping statement.  We certainly use it in some of our applications
>as a passive way to get a snapshot of thread activity and it works
>fine.

I am generally more interested in "practicality over purity".  And the
fact remains that 99% of the time that someone wants enumerate(), they
should have been storing references to thread objects in a list or dict;
that way, they're guaranteed to not make a mistake in trying to perform
some operation on the main thread.

I advocate against enumerate() for the same reasons I advocate against
Lock(), Condition(), Event(), and Semaphore().  (I strongly recommend
sticking with RLock() and Queue().)  Writing correct threaded
applications is difficult enough -- KISS, KISS, KISS.
-- 
                      --- Aahz  <*>  (Copyright 2002 by aahz at pobox.com)

Hugs and backrubs -- I break Rule 6                 http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista

"How come we choose from just two people for President but more than 50
for Miss America?"  --AEN