The Python Way

[David Bolen]

Tim Peters <tim.one at comcast.net> writes:

> [Andy Gimblett]
> > So, is Aahz/Tim saying that Queue.Queue is "better" in general than
> > threading.RLock ?  If so, why?
> 
> It's almost impossible to get yourself in trouble using Queue.  It's almost
> (but not quite as) impossible *not* to get yourself in trouble rolling your
> own protocols by hand via raw locks. (...)

And heck, in most cases with your own locking, you're bound to wrap it
up in some sort of container class to centralize your management of
the lock and its resource, and waddaya know - that's pretty much what
Queue is doing for you!

Assuming of course that it's for synchronizing data movement, I'm
always more than happy enough to delegate responsibility for it to
Queue, as a polished class known to be solid.

I'll still use locks as mutexes when I'm really just controlling
access to shared state that doesn't actually flow or fit a
producer/consumer concept, but that's about it.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/