<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 9 November 2014 04:42, Masklinn <span dir="ltr"><<a href="mailto:masklinn@masklinn.net" target="_blank">masklinn@masklinn.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 2014-11-08, at 16:04 , Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
> On Sat, 8 Nov 2014 14:05:07 +0100<br>
> Masklinn <<a href="mailto:masklinn@masklinn.net">masklinn@masklinn.net</a>> wrote:<br>
>><br>
>> A fairly small technical change I've been considering to improve this<br>
>> situation is to store the state-set inside the lock object, and only<br>
>> yield it through the context manager: that the state-set is protected<br>
>> by a lock is made obvious, and so is the relation between lock and<br>
>> state-set. I was delighted to discover that Rust's sync::Mutex[1] and<br>
>> sync::RWLock[2] follow a very similar strategy of owning the state-set<br>
>><br>
>> It's not a panacea, it doesn't fix issues of lock acquisition ordering<br>
>> for instance, but I think it would go a fairly long way towards making<br>
>> correct use of locks easier in Python.<br>
>><br>
>> The basic changes would be:<br>
>> * threading.Lock and threading.RLock would now take an optional<br>
>> `data` parameter<br>
>> * the parameter would be stored internally and not directly accessible<br>
>> by users of the lock<br>
>> * that parameter would be returned by __enter__ and provided to the<br>
>> current "owner" of the lock<br>
><br>
> For clarity it should probably be a separate class (or set of classes),<br>
> e.g. DataLock.<br>
<br>
</span>On the one hand this'd allow completely ignoring backwards-compatibility<br>
issues wrt acquire() which is nice, on the other hand it would double<br>
the number of lock types and introduce redundancy as DataLock would be<br>
pretty much a strict superset of Lock, which is why I thought extending<br>
Lock made sense.<br></blockquote><div><br></div></div>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.<br><br></div><div class="gmail_extra">It's also worth considering just always making DataLock recursive, and not worrying about the non-recursive variant.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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: <a href="http://wrapt.readthedocs.org/en/latest/wrappers.html">http://wrapt.readthedocs.org/en/latest/wrappers.html</a><br></div><div class="gmail_extra"><br clear="all"></div><div class="gmail_extra">Cheers,<br>Nick.<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>