Re: [Python-ideas] Store shared/locked state inside of the lock object

On 9 November 2014 04:42, Masklinn wrote:

On 2014-11-08, at 16:04 , Antoine Pitrou wrote:

...

On Sat, 8 Nov 2014 14:05:07 +0100 Masklinn 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.

On the one hand this'd allow completely ignoring backwards-compatibility issues wrt acquire() which is nice, on the other hand it would double the number of lock types and introduce redundancy as DataLock would be pretty much a strict superset of Lock, which is why I thought extending Lock made sense.

Merging it into Lock would make Lock itself harder to learn and use, so the separate DataLock notion sounds better to me - it keeps the documentation separate, so folks that just want a basic Lock or RLock don't need to care that DataLock exists. It's also worth considering just always making DataLock recursive, and not worrying about the non-recursive variant. If you'd like to experiment with this as a 3rd party module, Graham Dumpleton's wrapt library makes it possible to write almost completely transparent proxies in pure Python: http://wrapt.readthedocs.org/en/latest/wrappers.html Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia