[issue21137] Better repr for threading.Lock()
Berker Peksag
report at bugs.python.org
Wed Apr 30 20:32:10 CEST 2014
Berker Peksag added the comment:
Here's an updated patch. Thanks for the reviews.
> And of course we should keep "at 0x..." part, because it is the way to distinguish different lock objects.
Done.
$ ./python -c "import threading; l = threading.Lock(); print(l)"
<unlocked _thread.lock object at 0x7f0a19e7b1f8>
> The repr of threading._RLock contains owner and count, but not lock/unlock status.
Done.
$ ./python -c "import threading; rl = threading.RLock(); rl.acquire(); print(rl)"
<locked _thread.RLock object owner=139769600231168 count=1>
> The repr of locks from _dummy_thread also should contain lock/unlock status.
Done.
$ ./python -c "import dummy_threading as threading; l = threading.Lock(); print(l)"
<unlocked _dummy_thread.LockType object at 0x7fb334245400>
$ ./python -c "import dummy_threading as threading; l = threading.RLock(); print(l)"
<unlocked threading._RLock object owner=None count=0 at 0x7f524d0138e0>
> As for tests, I think assertRegex() will produce more useful error report.
Done.
----------
Added file: http://bugs.python.org/file35118/issue21137_v2.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21137>
_______________________________________
More information about the Python-bugs-list
mailing list