Jack> There will always be situations where you want to lock multiple Jack> objects, Michel> Can you be more explicit? I'm not sure I understand.
I have a multi-threaded XML-RPC server which, among lots of other bits of data maintains some "top 50" data (top 50 cities searched for, top 50 performers searched for, etc). Update time for that data is very fast relative to much of the other data maintained by the server. Rather than create a lock for each of the various "top 50" objects, I simply created a single top50_lock object and acquire and release it around manipulation of any of the various bits related to that stuff. Having a single lock means my code is simpler at the possible extra cost of only allowing a single thread into a larger chunk of code. OTOH, had I created multiple locks, performance might actually have gotten worse due to lock acquisition/release overhead.
Obviously I could have done things differently. I could have coalesced all the top 50 data into a single object and locked it or created a separate lock for each item.
would create a (hidden) lock for each item for you. Wouldn't this solve your problem of no two threads changing one item? or do changes to any one top 50 item *require* locking all 50? If they are independent that this is exactly the purpose PEP 319 serves.
Still, I agree with Jack that there are plenty of situations where you use one lock to lock multiple objects. (Consider the Python GIL as another example. ;-)
Isn't the interpreter one object in this case? Does the GIL lock anything else other than the interpreter?