[issue10789] Lock.acquire documentation is misleading

Alex Waygood added the comment: I am closing this issue. The original topic of discussion (Lock.acquire documentation) has been resolved, and there were other issues opened to discuss the more general issue. There has also been no real activity in this issue thread for a decade. --

[issue10789] Lock.acquire documentation is misleading

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10789] Lock.acquire documentation is misleading

Mark Lawrence added the comment: Has the Argument Clinic had an impact on this or is that a different kettle of fish? -- nosy: +BreamoreBoy versions: +Python 3.4, Python 3.5 -Python 3.1 ___ Python tracker rep...@bugs.python.org

[issue10789] Lock.acquire documentation is misleading

Éric Araujo mer...@netwok.org added the comment: I think this commit should be reverted: Arguments with default values no longer use brackets, see for example r73291. More info on #8350. -- nosy: +eric.araujo, georg.brandl ___ Python tracker

[issue10789] Lock.acquire documentation is misleading

Georg Brandl ge...@python.org added the comment: No, that's not true. Arguments that can't be given as kwargs are presented with brackets. However, the default value now isn't indicated anywhere; it should be added to the main text. -- ___ Python

[issue10789] Lock.acquire documentation is misleading

Terry J. Reedy tjre...@udel.edu added the comment: OK, I will add defaults in the texts and condense them a bit at the same time. Will post patches for review. Arguments that can't be given as kwargs are presented with brackets. I think this should be stated in the introduction to the Lib

[issue10789] Lock.acquire documentation is misleading

Éric Araujo mer...@netwok.org added the comment: Thanks for the correction Georg. In msg104113 (on #8350), I quoted http://docs.python.org/dev/reference/expressions#calls : “An implementation may provide built-in functions whose positional parameters do not have names, even if they are

[issue10789] Lock.acquire documentation is misleading

Raymond Hettinger rhettin...@users.sourceforge.net added the comment: I concur that the one warning is enough. Implementations have been given wide latitude in this regard. Even within CPython there is not much uniformity -- some funcs/methods don't accept keywords, some will disregard

[issue10789] Lock.acquire documentation is misleading

Terry J. Reedy tjre...@udel.edu added the comment: I responded to the general questions on #8350. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10789 ___

[issue10789] Lock.acquire documentation is misleading

Terry J. Reedy tjre...@udel.edu added the comment: Since threading is written in Python, one might expect Lock to be written in Python and its methods to accept keywords. However, threading.py (3.2) has _acquire_lock = _thread.acquire_lock Lock = _aquire_lock so threading.Lock objects are

[issue10789] Lock.acquire documentation is misleading

New submission from Jyrki Pulliainen jy...@dywypi.org: In threading module, the Lock.acquire documentation is misleading. The signature suggests that the blocking can be given as a keyword argument but that would lead to an TypeError, as thread.lock.acquire does not accept keyword arguments.