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

[Nick Coghlan]

On 9 November 2014 04:42, Masklinn <masklinn at masklinn.net> wrote:

> On 2014-11-08, at 16:04 , Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Sat, 8 Nov 2014 14:05:07 +0100
> > Masklinn <masklinn at 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.
>
> 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 at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141111/c0d17b33/attachment.html>