[issue14502] Document better what happens on releasing an unacquired lock

Jim Jewett report at bugs.python.org
Mon Apr 9 01:59:03 CEST 2012


Jim Jewett <jimjjewett at gmail.com> added the comment:

On Fri, Apr 6, 2012 at 10:32 PM, R. David Murray <report at bugs.python.org> wrote:

> R. David Murray <rdmurray at bitdance.com> added the comment:

> I, on the other hand, would prefer if it were made part of the API contract that an
> error is raised, and to fix any stdlib implementations *of that API* that don't conform
> to that.  (That is, locks from other modules may well not follow that API, and their
> documentation should cover their API.)

Do you consider it reasonable that all stdlib Locks follow that API,
and change to raise either RuntimeError or a subclass?

I don't feel comfortable declaring that (not even only for future
feature releases), but if you do, or Guido does, or ... etc ... I'll
submit patches for at least dummy_threading and logging.

-jJ

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14502>
_______________________________________


More information about the Python-bugs-list mailing list