The Python Way

[Aahz]

In article <mailman.1017275813.1746.python-list at python.org>,
Skip Montanaro  <skip at pobox.com> wrote:
>
>I wrote that I should look at replacing code like this
>
>    self.cache_lock.acquire()
>    try:
>        fiddle_some_cache...
>    finally:
>        self.cache_lock.release()
>
>with code like this
>
>    some_cache = self.some_cache_queue.get()
>    fiddle_some_cache...
>    self.some_cache_queue.put(some_cache)
>
>I eventually realized I can avoid the try/finally however.  If something
>happens within fiddle_some_cache... in the second code example I'd wind up
>with an empty queue.  So, if I needed try/finally in the acquire/release
>case, I will need it in the get/put case.  Silly me...

However, if you construct your dataflow such that an empty queue isn't a
problem, you don't need to use try/finally in your second example.  If
you're *just* using a queue to avoid an RLock() on a shared structure, go
ahead and use the RLock(); my point about using Queue.Queue is that too
many people try to pass data around using primitive/poor constructs.

Another point is that if your program would be broken (i.e. "should
crash") if fiddle_some_cache fails, you probably shouldn't bother with
the try/finally.  Go ahead and force a core dump.  ;-)
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Why is this newsgroup different from all other newsgroups?