[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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 rewrite reprs of locks, conditions 
and synchronization primitives in asyncio and multiprocessing to match this 
style: move status after type and address, remove parenthesis, brackets and 
commas, use "=" instead of ":" for named values, use "/" with maximal values, 
etc.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 exceptions are asyncio (just because it constructs reprs from 
super().__repr__(), including verbose "object" after type name), 
concurrent.futures and weakref.finalize (the latter contains multiple addresses 
in any case). Do we need "object" after type name?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24391] Better repr for threading objects

2015-09-14 Thread STINNER Victor

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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, BoundedSemaphore, and Barrier, it attempts to directly mirror 
the threading module's equivalents.  If there's a change to the reprs for these 
in the threading module, then given the special relationship between 
multiprocessing and threading, I suggest it is worth the effort to update 
multiprocessing accordingly.

I have created issue25066 to separately address this proposed change to 
multiprocessing.

I've gone ahead and provided a patch for issue25066 to reflect the "majority 
opinion" on the reprs' desired format.  That patch should pass all tests once 
Serhiy's patch is similarly updated to match what Larry summarized.

If this issue does reach a happy conclusion and Serhiy finds time to update his 
patch, would someone please also take a moment to review the patch in 
issue25066?

--
nosy: +davin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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: +rbcollins
stage: commit review - patch review

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24391
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 'parallel' modules, so their reps should follow 
the same pattern.

--
nosy: +terry.reedy

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24391
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 asyncio reprs.  Specifically, I like how the interesting 
things (class, interesting values) are at the front and rear, and the address 
is in the middle.  While it's occasionally helpful (or even crucial!) to show 
the address, I *almost* never need to look at it.  Arranging the data in this 
way makes it easy to skip over the address when reading.

However, I don't think the parentheses or square brackets are necessary.  It's 
not like this is a computer-readable syntax, and for human beings it's just 
visual clutter.  I suggest it's sufficient to have comma separated values with 
a space after each comma.  Also: I definitely don't like the colon after the 
class name.

So here's how *I* might reformat all your examples:

threading.Semaphore at 0xb710ec8c 10
threading.BoundedSemaphore at 0xb6ff1d6c 7/10
threading.Event at 0xb710ec8c unset
threading.Event at 0xb710ec8c set
threading.Barrier at 0xb6ff1d6c 0/10
threading.Barrier at 0xb6ff1d6c 3/10
threading.Barrier at 0xb6ff1d6c 0/10, broken

p.s. Thank you for posting these samples of other approaches!  It definitely 
shed some light into the discussion.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24391
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 0xb710ec8c
set Event at 0xb710ec8c
Barrier: 0/10 at 0xb6ff1d6c
Barrier: 3/10 at 0xb6ff1d6c
broken Barrier: 3/10 at 0xb6ff1d6c

--
components: Library (Lib)
messages: 244896
nosy: berker.peksag, brett.cannon, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Better repr for threading objects
type: enhancement
versions: Python 3.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24391
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 instead of an Event that is set.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24391
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 count=2 at 0xb6f2b0b0

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24391
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 rep...@bugs.python.org
http://bugs.python.org/issue24391
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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
http://bugs.python.org/issue24391
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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 tracker rep...@bugs.python.org
http://bugs.python.org/issue24391
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24391
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[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: 0/10 at 0xb6ff1d6c
threading.Barrier: 3/10 at 0xb6ff1d6c
threading.Barrier: 0/10, broken at 0xb6ff1d6c

But there is other question. Should reprs be consistent with reprs of 
corresponding classes in multiprocessing and asyncio modules?

In multiprocessing:

Semaphore(value=10)
BoundedSemaphore(value=10, maxvalue=10)

In asyncio:

asyncio.locks.Event object at 0xb6fa180c [unset]
asyncio.locks.Event object at 0xb6fa180c [set]
asyncio.locks.Event object at 0xb6fa180c [unset,waiters:3]
asyncio.locks.Semaphore object at 0xb6cec26c [unlocked,value:10]
asyncio.locks.Semaphore object at 0xb6cec26c [locked]
asyncio.locks.Semaphore object at 0xb6cec26c [locked, waiters:3]

--
Added file: http://bugs.python.org/file39642/threading_objects_reprs_2.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24391
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com