On Sat, 8 Nov 2014 14:05:07 +0100 Masklinn <masklinn@masklinn.net> wrote:
A fairly small technical change I've been considering to improve this situation is to store the state-set inside the lock object, and only yield it through the context manager: that the state-set is protected by a lock is made obvious, and so is the relation between lock and state-set. I was delighted to discover that Rust's sync::Mutex[1] and sync::RWLock[2] follow a very similar strategy of owning the state-set
It's not a panacea, it doesn't fix issues of lock acquisition ordering for instance, but I think it would go a fairly long way towards making correct use of locks easier in Python.
The basic changes would be: * threading.Lock and threading.RLock would now take an optional `data` parameter * the parameter would be stored internally and not directly accessible by users of the lock * that parameter would be returned by __enter__ and provided to the current "owner" of the lock
For clarity it should probably be a separate class (or set of classes), e.g. DataLock. Regards Antoine.