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 josh.r
Recipients docs@python, josh.r, smbrd
Date 2016-03-23.02:49:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1458701376.11.0.696104187632.issue26608@psf.upfronthosting.co.za>
In-reply-to
Content
Per the docs ( https://docs.python.org/3/library/threading.html#rlock-objects ):

"To unlock the lock, a thread calls its release() method. acquire()/release() call pairs may be nested; only the final release() (the release() of the outermost pair) resets the lock to unlocked and allows another thread blocked in acquire() to proceed."

The docs aren't super clear on the return type, but they aren't so overly specified as to make returning either True or 1 incorrect; they use lowercase "true" to describe the return value, which doesn't *have* to mean True, just something that evaluates as truthy.

In 3.5 at least, it looks like both initial and subsequent acquires are all returning True, even when called without passing an argument; this actually violates the docs, which claim that not passing an argument means "There is no return value" (possibly only when there is contended acquisition, the wording is odd), when in fact a no-argument call returns True just like explicitly passing blocking as True.
History
Date User Action Args
2016-03-23 02:49:36josh.rsetrecipients: + josh.r, docs@python, smbrd
2016-03-23 02:49:36josh.rsetmessageid: <1458701376.11.0.696104187632.issue26608@psf.upfronthosting.co.za>
2016-03-23 02:49:36josh.rlinkissue26608 messages
2016-03-23 02:49:35josh.rcreate