[issue24391] Better repr for threading objects

2021-09-29 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: New changeset eed32df5b6b989caf125d829301546db58b529dd by Serhiy Storchaka in branch 'main': bpo-24391: Better reprs for threading objects. (GH-20534) https://github.com/python/cpython/commit/eed32df5b6b989caf125d829301546db58b529dd --

[issue24391] Better repr for threading objects

2021-09-27 Thread Serhiy Storchaka
Change by Serhiy Storchaka : -- versions: +Python 3.11 -Python 3.5, Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue24391] Better repr for threading objects

2021-09-27 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: In the last version of PR 20534, the reprs will be similar to proposed by Larry in msg244958, except that a colon is used to separate an address from status, and keyword names are used for values. It is closer to existing reprs, I'm going to

[issue24391] Better repr for threading objects

2020-05-30 Thread Serhiy Storchaka
Change by Serhiy Storchaka : -- pull_requests: +19778 pull_request: https://github.com/python/cpython/pull/20534 ___ Python tracker ___

[issue24391] Better repr for threading objects

2020-05-29 Thread Brett Cannon
Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24391] Better repr for threading objects

2020-05-29 Thread Brett Cannon
Brett Cannon added the comment: Assigning to Serhiy in case he wants to finish this. -- assignee: -> serhiy.storchaka ___ Python tracker ___

[issue24391] Better repr for threading objects

2016-09-10 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: I agree, that the address is the least interesting thing, and I think this is an argument to make it the last thing in the repr (at least for those of us who read from left to right). Many objects in different modules outputs the address last. The only

[issue24391] Better repr for threading objects

2015-09-14 Thread STINNER Victor
Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___

[issue24391] Better repr for threading objects

2015-09-10 Thread Davin Potts
Davin Potts added the comment: Echoing Larry's insightful summary, it would not be particularly rewarding to pursue a goal of making the whole world of reprs consistent. But as Antoine and Serhiy began to point out, the multiprocessing module not only has its own Event, Semaphore,

[issue24391] Better repr for threading objects

2015-08-05 Thread Robert Collins
Robert Collins added the comment: So, I think the majority opinion seems to be: module.type at address value1, value2, ... AIUI the patch doesn't quite do that, so I'm going to pop this back to patch review. That said, Serhiy, if you fix it up, just commit it please :) -- nosy:

[issue24391] Better repr for threading objects

2015-06-12 Thread Terry J. Reedy
Terry J. Reedy added the comment: The Semaphore and BoundedSemphore examples show why including the module is helpful. I prefer the function-call syntax, as long as it is accurate, even though the string as a whole cannot be eval()-ed. In any case, threading and multiprocessing are somewhat

[issue24391] Better repr for threading objects

2015-06-07 Thread Larry Hastings
Larry Hastings added the comment: The world of reprs already isn't particularly consistent. If you make your reprs consistent with module X, it'll be *inconsistent* with module Y, and vice versa. I say let's just worry about making it nice and readable for humans. That said, I like the

[issue24391] Better repr for threading objects

2015-06-06 Thread Berker Peksag
Changes by Berker Peksag berker.pek...@gmail.com: -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24391 ___

[issue24391] Better repr for threading objects

2015-06-06 Thread Serhiy Storchaka
Changes by Serhiy Storchaka storch...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file39637/threading_objects_reprs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24391

[issue24391] Better repr for threading objects

2015-06-06 Thread Serhiy Storchaka
New submission from Serhiy Storchaka: Proposed patch adds makes reprs of threading objects Semaphore, BoundedSemaphore, Event, and Barrier expose their public states. This will help for debugging. Examples: Semaphore: 10 at 0xb710ec8c BoundedSemaphore: 7/10 at 0xb6ff1d6c unset Event at

[issue24391] Better repr for threading objects

2015-06-06 Thread Antoine Pitrou
Antoine Pitrou added the comment: +1. The patch looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24391 ___ ___ Python-bugs-list

[issue24391] Better repr for threading objects

2015-06-06 Thread Brett Cannon
Brett Cannon added the comment: While I like the concept, I don't like the reprs where the type is not the first thing listed, e.g., set Event not having Event first. The default repr and typical practice of having the type come first makes my brain initially read that repr as a set of Events

[issue24391] Better repr for threading objects

2015-06-06 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: This is for consistency with reprs of lock objects (issue21137): unlocked _thread.lock object at 0xb6f2b188 locked _thread.lock object at 0xb6f2b188 unlocked _thread.RLock object owner=0 count=0 at 0xb6f2b0b0 locked _thread.RLock object owner=-1219680512

[issue24391] Better repr for threading objects

2015-06-06 Thread Antoine Pitrou
Antoine Pitrou added the comment: I'd like to see this in 3.5. This is a no-brainer improvement and has very little chance of breaking anything compared to a new OrderedDict implementation. -- nosy: +larry versions: +Python 3.5 ___ Python tracker

[issue24391] Better repr for threading objects

2015-06-06 Thread Larry Hastings
Larry Hastings added the comment: I'll allow it. But I agree with Brett, I really would prefer that the type be the first thing in the repr. I'd rather fix the lock objects than compound our error. -- ___ Python tracker rep...@bugs.python.org

[issue24391] Better repr for threading objects

2015-06-06 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: Would following reprs good? Event: set at 0xb710ec8c Event: unset at 0xb710ec8c (what is better: unset or clear?) Should the repr contain the module name (threading.Event: set at 0xb710ec8c)? -- ___ Python

[issue24391] Better repr for threading objects

2015-06-06 Thread Antoine Pitrou
Antoine Pitrou added the comment: I think the module name is useful, since there are also multiprocessing events and semaphores. Also, Event is a fairly generic name which may be used in other contexts (e.g. GUI libraries). set and unset sound good to me. --

[issue24391] Better repr for threading objects

2015-06-06 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: Here is updated patch. Now the repr always starts with the qualified class name. threading.Semaphore: 10 at 0xb710ec8c threading.BoundedSemaphore: 7/10 at 0xb6ff1d6c threading.Event: unset at 0xb710ec8c threading.Event: set at 0xb710ec8c threading.Barrier: