Q abon...@gmail.com added the comment:
My bad. That's indeed what I did. Won't repeat the mistake, sorry.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14823
___
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 6ab4128a by R David Murray in branch '3.2':
#14823: Simplify threading.Lock.acquire argument discussion.
http://hg.python.org/cpython/rev/6ab4128a
New changeset b5e95bb79ba3 by R David Murray in branch
R. David Murray rdmur...@bitdance.com added the comment:
Instead I decided to go ahead and document the argument as True/False. That
something else is accepted is a CPython implementation detail that shouldn't be
depended on.
By the way, I couldn't actually use your patch file, since it
Éric Araujo mer...@netwok.org added the comment:
I suspect the patch was made against the source files served by Sphinx with a
txt extension.
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14823
Q abon...@gmail.com added the comment:
Well, as threading is a Python wrapper, this could easily be fixed. (I am not
certain whether it *should* be fixed or not -- perhaps things are fine just as
they are, at least with that particular detail. )
But this is good to know, thank you.
New submission from Q abon...@gmail.com:
Hi there,
I suggest to improve the description of Lock.acquire()
[ http://docs.python.org/library/threading.html#threading.Lock.acquire ]
in the following way:
current version
Lock.acquire([blocking])
Acquire a lock, blocking or non-blocking.
R. David Murray rdmur...@bitdance.com added the comment:
Thanks for the suggestion and the patch.
The 'true' isn't inherited from java. The actual value can be either an
integer or True/False. (If it were a function written in Python it would be
any value that evaluates as true, but because
