On Sun, Jul 19, 2020, at 13:02, Guido van Rossum wrote:
> That looks expensive, esp. for objects implemented in Python — an extra
> dict entry plus a new unique int object. What is the problem you are
> trying to solve for these objects specifically? Just that the hex
> numbers look distracting
Hi Serhiy,
Can I suggest using a short hash of the id as a prefix to the id?
would become something like:
This approach uses no extra memory in the object and makes similar
objects more visually distinct.
It fails to make the repr shorter, and the hashed ids are not globally
unique.
T
On 19/07/2020 16:38, Serhiy Storchaka wrote:
I have problem with the location of hexadecimal memory address in
custom reprs.
I agree they are "noise" mostly and difficult to distinguish when you
need to.
What if use serial numbers to differentiate instances?
where the serial number sta
19.07.20 22:17, Antoine Pitrou пише:
How about putting it in parentheses, to point more clearly that it can
most of the time be ignored:
It will just make the repr 2 characters longer and will not solve other
problems (that first and last digits of the identifier of different
objects usu
19.07.20 23:30, Thomas Moreau пише:
While it would be nice to have simpler identifiers for objects, it would
be hard to make it work for multiprocessing, as objects in different
interpreter would end up having the same repr. Shared objects (locks)
might also have different serial numbers depend
19.07.20 20:02, Guido van Rossum пише:
That looks expensive, esp. for objects implemented in Python — an extra
dict entry plus a new unique int object. What is the problem you are
trying to solve for these objects specifically? Just that the hex
numbers look distracting doesn’t strike me as suf
On Sat, Jul 25, 2020 at 12:03:55PM +0300, Serhiy Storchaka wrote:
> 19.07.20 19:33, Steven D'Aprano пише:
> No, I do not propose to change object IDs. I proposed only to use serial
> numbers instead of IDs in reprs of some classes.
Yes, I understood that you were only talking about reprs, and on
19.07.20 19:33, Steven D'Aprano пише:
On Sun, Jul 19, 2020 at 06:38:30PM +0300, Serhiy Storchaka wrote:
What if use serial numbers to differentiate instances?
I like this idea. It is similar to how Jython and IronPython object IDs
work:
# Jython
>>> id(None)
2
>>> id(len
On Sun, Jul 19, 2020 at 1:34 PM Thomas Moreau
wrote:
> While it would be nice to have simpler identifiers for objects, it would
> be hard to make it work for multiprocessing, as objects in different
> interpreter would end up having the same repr. Shared objects (locks) might
> also have differen
On 7/19/20 4:30 PM, Thomas Moreau wrote:
> Dear all,
>
> While it would be nice to have simpler identifiers for objects, it
> would be hard to make it work for multiprocessing, as objects in
> different interpreter would end up having the same repr. Shared
> objects (locks) might also have differen
Dear all,
While it would be nice to have simpler identifiers for objects, it would be
hard to make it work for multiprocessing, as objects in different
interpreter would end up having the same repr. Shared objects (locks) might
also have different serial numbers depending on how many objects have
On Sun, 19 Jul 2020 18:38:30 +0300
Serhiy Storchaka wrote:
> I have problem with the location of hexadecimal memory address in custom
> reprs.
>
>
>
> vs
>
>
How about putting it in parentheses, to point more clearly that it can
most of the time be ignored:
> I do not propose
That looks expensive, esp. for objects implemented in Python — an extra
dict entry plus a new unique int object. What is the problem you are trying
to solve for these objects specifically? Just that the hex numbers look
distracting doesn’t strike me as sufficient motivation.
On Sun, Jul 19, 2020 a
On Sun, Jul 19, 2020 at 06:38:30PM +0300, Serhiy Storchaka wrote:
> What if use serial numbers to differentiate instances?
I like this idea. It is similar to how Jython and IronPython object IDs
work:
# Jython
>>> id(None)
2
>>> id(len)
3
>>> object()
> I do not
14 matches
Mail list logo
