[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