This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Jim.Jewett, docs@python, georg.brandl, pitrou, python-dev, r.david.murray, sandro.tosi, vinay.sajip
Date 2012-04-09.19:31:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1333999534.3379.31.camel@localhost.localdomain>
In-reply-to <CA+OGgf5Cr+NOzpd=qkn9jJQG-=_Auo5WsngQNuAz3wPT2H-XQA@mail.gmail.com>
Content
> The current question is what contract locks should follow, and whether
> all locks should follow it.  Would it be acceptable for
> logging._releaseLock to raise a RuntimeError if the lock hadn't
> previously been acquired?

I don't see the point of this discussion. We are talking about
threading.Lock (and, possibly, multiprocessing.Lock), not every lock API
under the sun. Especially when it's a private API...
History
Date User Action Args
2012-04-09 19:31:04pitrousetrecipients: + pitrou, georg.brandl, vinay.sajip, r.david.murray, sandro.tosi, docs@python, python-dev, Jim.Jewett
2012-04-09 19:31:03pitroulinkissue14502 messages
2012-04-09 19:31:03pitroucreate