[Python-Dev] Re: Memory address vs serial number in reprs

2020-07-25 Thread Random832
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

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

2020-07-25 Thread Chris Jerdonek
On Sat, Jul 25, 2020 at 12:17 PM Jim J. Jewett wrote: > I certainly understand saying "this change isn't important enough to > justify a change." > > But it sounds as though you are saying the benefit is irrelevant; Jim, if you include what you’re replying to in your own message (like I’m

[Python-Dev] PEP 622: Structural Pattern Matching -- followup

2020-07-25 Thread Eric Nieuwland
On 24/06/2020 20:38, Guido van Rossum wrote: > Everyone, > > If you've commented and you're worried you haven't been heard, please=20 > add your issue *concisely* to this new thread. Note that the following=20 > issues are already open and will be responded to separately; please=20 > don't bother

[Python-Dev] PEP 622: Structural Pattern Matching -- followup

2020-07-25 Thread Eric Nieuwland
> On 25 Jul 2020, at 03:44, Rob Cliffe wrote: > > Without arguing for or against allowing a capture variable, IMO rather > than syntax like >match into : > it would be far better (and not require a new keyword) to write this as >with as match : > > On 24/06/2020 20:38, Guido van

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

2020-07-25 Thread Jim J. Jewett
I certainly understand saying "this change isn't important enough to justify a change." But it sounds as though you are saying the benefit is irrelevant; it is just inherently too expensive to ask programs that are already dealing with internals and trying to optimize performance to make a

[Python-Dev] Re: Python-Dev Digest, Vol 204, Issue 129

2020-07-25 Thread Eric Nieuwland
On 24/06/2020 20:38, Guido van Rossum wrote: > Everyone, > > If you've commented and you're worried you haven't been heard, please=20 > add your issue *concisely* to this new thread. Note that the following=20 > issues are already open and will be responded to separately; please=20 > don't bother

[Python-Dev] Re: Python-Dev Digest, Vol 204, Issue 129

2020-07-25 Thread Eric Nieuwland
> On 25 Jul 2020, at 03:44, Rob Cliffe wrote: > > Without arguing for or against allowing a capture variable, IMO rather > than syntax like > match into : > it would be far better (and not require a new keyword) to write this as > with as match : > > On 24/06/2020 20:38, Guido van

[Python-Dev] Re: Memory address vs serial number in reprs

2020-07-25 Thread Mark Shannon
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.

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

2020-07-25 Thread Rob Cliffe via Python-Dev
Without arguing for or against allowing a capture variable, IMO rather than syntax like     match into : it would be far better (and not require a new keyword) to write this as     with as match : Rob Cliffe On 24/06/2020 20:38, Guido van Rossum wrote: Everyone, If you've commented and

[Python-Dev] Re: Memory address vs serial number in reprs

2020-07-25 Thread Jeff Allen
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

[Python-Dev] Re: Memory address vs serial number in reprs

2020-07-25 Thread Serhiy Storchaka
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

[Python-Dev] Re: Memory address vs serial number in reprs

2020-07-25 Thread Serhiy Storchaka
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

[Python-Dev] Re: Memory address vs serial number in reprs

2020-07-25 Thread Serhiy Storchaka
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

[Python-Dev] Re: Memory address vs serial number in reprs

2020-07-25 Thread Steven D'Aprano
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

[Python-Dev] Re: Memory address vs serial number in reprs

2020-07-25 Thread Serhiy Storchaka
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 >>>