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 been created before it is communicated to the child process.
Le dim. 19 juil. 2020 à 21:26, Antoine Pitrou firstname.lastname@example.org a écrit :
On Sun, 19 Jul 2020 18:38:30 +0300 Serhiy Storchaka email@example.com wrote:
I have problem with the location of hexadecimal memory address in custom reprs.
<threading.BoundedSemaphore: 2/3 at 0x7ff4c26b3eb0>
<threading.BoundedSemaphore at 0x7ff4c26b3eb0: 2/3>
How about putting it in parentheses, to point more clearly that it can most of the time be ignored:
<threading.BoundedSemaphore: 2/3 (at 0x7ff4c26b3eb0)>
I do not propose to use serial numbers for all objects, because it would increase the size of objects and the fixed-size integer can be overflowed for some short-living objects created in mass (like numbers, strings, tuples). But only for some custom objects implemented in Python, for which size and creation time are not critical. I want to start with synchronization objects in threading and multiprocessing which did not have custom reprs, than change reprs of locks and asyncio objects.
Is it worth to do?
I would like it if it applied to all objects, but doing it only for certain objects will be distracting and confusing (does the serial number point to a specific feature? it turns out it doesn't, it's just an arbitrary aesthetical choice).
Python-Dev mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://firstname.lastname@example.org/message/7ZSD6GHN... Code of Conduct: http://python.org/psf/codeofconduct/