Davin Potts added the comment: In the docs for 2.7, multiprocessing.Lock refers to threading.Lock in which the signature for acquire looks like: threading.Lock.acquire([blocking]) However, in the current code in 2.7, Modules/_multiprocessing/semaphore.c implements multiprocessing.Lock.acquire to support two arguments: 'block' and 'timeout'. In the docs for 3.4, threading.Lock.acquire now has both 'blocking' and 'timeout' arguments. Notably, it specifies: "It is forbidden to specify a timeout when blocking is false." This is indeed enforced by threading.Lock but not at all by multiprocessing.Lock. In a 3.4.3 shell: >>> import multiprocessing >>> import threading >>> ml = multiprocessing.Lock() >>> ml.acquire(False, 20.0) True >>> ml.release() >>> tl = threading.Lock() >>> tl.acquire(False, 20.0) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: can't specify a timeout for a non-blocking call In 2.7, acquire similarly permits a supplied value for timeout even when set to be non-blocking. A further difference: the code in Modules/_multiprocessing/semaphore.c appears to translate a timeout=None into an infinite wait whereas the threading implementation rejects any attempt to supply a None for timeout, demanding a float instead. (In 3.4, threading uses timeout=-1 to request an infinite wait.) Given these discrepancies between threading's and multiprocessing's implementations for Lock and given the difficulties in renaming an argument that can be supplied as a non-keyword parameter, the right thing to do at this point is to properly document multiprocessing.Lock's acquire as using 'block' and 'timeout'. ---------- assignee: -> docs@python components: +Documentation -Extension Modules nosy: +docs@python _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue23484> _______________________________________