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

[Ethan Furman]

On 11/08/2014 10:42 AM, 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 and
>>> sync::RWLock follow a very similar strategy of owning the state-set
>>
>> 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.

How does transforming existing locks into this kind of lock benefit existing code?  If existing code has to change to 
take advantage of the new features, said code could just as easily change the name of the lock it was using.

--
~Ethan~