[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Roundup Robot added the comment: New changeset f3faf0f355e0 by Berker Peksag in branch '3.4': Issue #23484: Document differences between synchronization primitives of https://hg.python.org/cpython/rev/f3faf0f355e0 New changeset 6cd030099966 by Berker Peksag in branch '3.5': Issue #23484:

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Roundup Robot added the comment: New changeset 92350a2a8b08 by Berker Peksag in branch '2.7': Issue #23484: Document differences between synchronization primitives of https://hg.python.org/cpython/rev/92350a2a8b08 -- ___ Python tracker

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Berker Peksag added the comment: Thanks, Teodor and Davin! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Changes by Berker Peksag : -- assignee: docs@python -> berker.peksag versions: +Python 3.6 ___ Python tracker ___

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Davin Potts added the comment: @berker.peksag, @r.david.murray: Could I gently nudge one of you into committing the final versions of these patches? -- ___ Python tracker

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Davin Potts added the comment: Updating patch for default/3.5 and 3.4 branches to remove versionchanged message on {Lock,RLock}.acquire per feedback from @berker. -- Added file: http://bugs.python.org/file38867/issue_23484_doc_locks_py35_and_py34_noverchange.patch

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Davin Potts added the comment: Same for 2.7 branch. -- Added file: http://bugs.python.org/file38868/issue_23484_doc_locks_py27_noverchange.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23484

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Davin Potts added the comment: @berker: Sadly, I've read those descriptions in triaging.html more than once and that part apparently did not stick in my head. Hopefully it will now -- thanks. @r.david: Ok, cool -- I had been mentally associating more significance to one versus the other

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

R. David Murray added the comment: behavior vs enhancment for doc changes is really pretty meaningless/arbitrary, IMO. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23484

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Berker Peksag added the comment: I use enhancement for non-trivial documentation patches. Also, quoting from https://docs.python.org/devguide/triaging.html#type Also used for improvements in the documentation and test suite and for other refactorings. In this case, your patch fixes a

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Davin Potts added the comment: @berker: I would have said this should not be marked an enhancement as the proposed solution (in the patch) is to correct the errors in the documentation to accurately describe the current implemented behavior. Does that make sense? Whatever label we give it,

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag type: behavior - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23484 ___

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Davin Potts added the comment: Attaching patches for 3.5/default, 3.4, and 2.7 which update the documentation on multiprocessing.Lock, RLock, Semaphore, and BoundedSemaphore to describe their actual implemented behavior, replacing the existing, misleading claim that they are clones of

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Changes by Davin Potts pyt...@discontinuity.net: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23484 ___ ___ Python-bugs-list

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Changes by Davin Potts pyt...@discontinuity.net: Added file: http://bugs.python.org/file38703/issue_23484_doc_locks_py27.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23484 ___

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Davin Potts added the comment: To be fair, the docs in 2.7 do actually mention the use of 'block' instead of 'blocking' in acquire though it does so inside a Note block a bit later in the docs after first claiming that multiprocessing.Lock is a clone. In 3.4, that important detail has been

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

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

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Teodor Dima added the comment: Of course, there's code in the wild that expects and uses the parameter named 'block' so simply changing this keyword will result in breaking others' code. That is, indeed, the case with my company's code as well. --

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Changes by Ned Deily n...@acm.org: -- nosy: +davin, sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23484 ___ ___ Python-bugs-list mailing list

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Davin Potts added the comment: Interesting! The documentation in 3.4 as well as 2.7 indicates that the keyword should be 'blocking' yet the code implements this as 'block'. Code to reproduce empirically what is actually implemented: import multiprocessing dummy_lock = multiprocessing.Lock()

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

Davin Potts added the comment: Of course, there's code in the wild that expects and uses the parameter named 'block' so simply changing this keyword will result in breaking others' code. Two potentially appealing options: 1) Document that acquire in multiprocessing differs from threading in

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid

New submission from Teodor Dima: The keyword for 'blocking' in the documentation for multiprocessing.Lock.acquire() (and all synchronization objects dependent on SemLock) differs from its implementation at Modules/_multiprocessing/semaphore.c:70 -