[issue21137] Better repr for threading.Lock()

2014-05-25 Thread Berker Peksag
Changes by Berker Peksag : -- stage: patch review -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue21137] Better repr for threading.Lock()

2014-05-25 Thread Raymond Hettinger
Raymond Hettinger added the comment: Thanks Berker. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-

[issue21137] Better repr for threading.Lock()

2014-05-25 Thread Roundup Robot
Roundup Robot added the comment: New changeset 7574f94b1068 by Raymond Hettinger in branch 'default': Issue 21137: Better repr for threading.Lock() http://hg.python.org/cpython/rev/7574f94b1068 -- nosy: +python-dev ___ Python tracker

[issue21137] Better repr for threading.Lock()

2014-05-22 Thread Berker Peksag
Berker Peksag added the comment: Here is a new patch. I've disabled test_repr and test_locked_repr tests in Lib/test/test_importlib/test_locks.py. -- Added file: http://bugs.python.org/file35321/issue21137_v3.diff ___ Python tracker

[issue21137] Better repr for threading.Lock()

2014-05-22 Thread Raymond Hettinger
Raymond Hettinger added the comment: The patch is just about ready to go but needs to address some failing tests: == FAIL: test_locked_repr (test.test_importlib.test_locks.Frozen_ModuleLockAsRLockTests)

[issue21137] Better repr for threading.Lock()

2014-05-22 Thread Raymond Hettinger
Changes by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue21137] Better repr for threading.Lock()

2014-04-30 Thread Berker Peksag
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)" > The repr of thre

[issue21137] Better repr for threading.Lock()

2014-04-28 Thread Antoine Pitrou
Antoine Pitrou added the comment: > The repr of threading._RLock contains owner and count, but not > lock/unlock status. The repr of locks from _dummy_thread also should > contain lock/unlock status. And it would be nice to have the > open/closed status in the repr of other synchronization primit

[issue21137] Better repr for threading.Lock()

2014-04-03 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: And of course we should keep "at 0x..." part, because it is the way to distinguish different lock objects. -- ___ Python tracker ___

[issue21137] Better repr for threading.Lock()

2014-04-03 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: The repr of threading._RLock contains owner and count, but not lock/unlock status. The repr of locks from _dummy_thread also should contain lock/unlock status. And it would be nice to have the open/closed status in the repr of other synchronization primitive

[issue21137] Better repr for threading.Lock()

2014-04-02 Thread Berker Peksag
Berker Peksag added the comment: Here's a patch with a test. Example repr of threading.Lock(): $ ./python -c "import threading; print(threading.Lock())" -- keywords: +patch nosy: +berker.peksag Added file: http://bugs.python.org/file34710/issue21137.diff __

[issue21137] Better repr for threading.Lock()

2014-04-02 Thread Raymond Hettinger
New submission from Raymond Hettinger: It is really nice to have the open/closed status in the __repr__ of file objects: I would like to have the same for locks: This would be nice in logs and tracebacks for example. -- components: Library (Lib) keywords: easy messages: