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

[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
 >>> id(len)
 3
 >>> object()
 


No, I do not propose to change object IDs. I proposed only to use serial 
numbers instead of IDs in reprs of some classes.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PJOBIIV52J3AHKT7SBVQLPMY46SS36AO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 only for a 
few classes. I was pointing out a similarity, that was all.

I'm sorry if I wasn't clear enough.

-- 
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/S5RXFXDPMVN77X56LPZDAIK3ZZQVRVWK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

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


It is the main problem that I want to solve. " at 0x7ff4c26b3eb0" is 18 
characters long, and first and last digits usually are the same for 
different objects.


Also, since objects can reuse memory after destroying other objects, 
unique identifier can help to analyze logs.


It is not so expensive. New dict entry does not cost anything if the 
object already has a dict (space for 5 entries is reserved from the 
start). The size of small integer up to 2**30 is 28 bytes, and integers 
up to 255 does not cost anything. It is minor in comparison with the 
Python object size (48 bytes), dict size (104 bytes), and the size of 
other object attributes (locks, counters, etc). It is very unlikely the 
program will have millions of semaphores or event objects at one time, 
it is most likely it will use tens of them.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/P2KSIMU3FHWBCHVPRLF2QBLLWYZM6ILA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 depending on how many objects 
have been created before it is communicated to the child process.


Multiprocessing synchronization objects can include PID in the repr.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NLQL3UYEGG4PLUMWDSIXIZMYPIPU5YI4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 usually are the same, and that the same identifier can be used 
for different objects in different time).

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MFQLJFTTORI7QV5JCBZPJ6WPFRPX2WLG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 starts with 1 and increased for every new 
instance of that type.


What would happen at a __class__ assignment?

IIUC class assignability is an equivalence relation amongst types: 
serial numbers would have to be unique within the equivalence class, not 
within the type. Otherwise, they would have to change (unlike id()), may 
not round-trip if __class__ were assigned there and back.


Jeff Allen

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/THVJFA3INNGWW2CXDKGFTMASH3UURAYG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 you're worried you haven't been heard, please 
add your issue *concisely* to this new thread. Note that the following 
issues are already open and will be responded to separately; please 
don't bother commenting on these until we've done so:


- Alternative spellings for '|'
- Whether to add an 'else' clause (and how to indent it)
- A different token for wildcards instead of '_'
- What to do about the footgun of 'case foo' vs. 'case .foo'

(Note that the last two could be combined, e.g. '?foo' or 'foo?' to 
mark a variable binding and '?' for a wildcard.)


--
--Guido van Rossum (python.org/~guido )
/Pronouns: he/him //(why is my pronoun here?)/ 



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/STJSSAETMTUY7FK5AE53IM73Z2WORNYN/
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TAF5VNJ4IXLIHV2WW3F6MNCLHGTK5OGW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

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


The hash doesn't need to be secure, just have a good spread.

Cheers,
Mark.

On 19/07/2020 4:38 pm, Serhiy Storchaka wrote:
I have problem with the location of hexadecimal memory address in custom 
reprs.


     

vs

     

The long hexadecimal number makes the repr longer and distracts 
attention from other useful information. We could get rid of it, but it 
is useful if we want to distinguish objects of the same type. Although 
it is hard to distinguish long hexadecimal numbers which differ only by 
few digits in the middle.


What if use serial numbers to differentiate instances?

     

where the serial number starts with 1 and increased for every new 
instance of that type.


The advantages are:

* Shorter repr.
* Easier to distinguish different objects.
* The serial number is unique for the life of program and cannot be 
reused (in contrary to id/memory address).


The disadvantages are:

* Increased object size and creation time.

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?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E6YEXMQ4OE5YGZGRP62JOLTAGBCL6RCX/ 


Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TMLOB3JIU6SA5EWJX7YLJCDNBHTE4DRG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 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 commenting on these until we've done so:
>> 
>> - Alternative spellings for '|'
>> - Whether to add an 'else' clause (and how to indent it)
>> - A different token for wildcards instead of '_'
>> - What to do about the footgun of 'case foo' vs. 'case .foo'
>> 
>> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to=20
>> mark a variable binding and '?' for a wildcard.)
>> 

We already have 'with' for contexts.


We already have patterns with 'as':
-   except expression "as" identifier ":"
-   "import" module "as" identifier
-   "with"  expression "as" target


So I think this would be quite confusing.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/U27FYK4U34M7FGDIUTDQZCNAU2MV7UNW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 commenting on these until we've done so:
> 
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
> 
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to=20
> mark a variable binding and '?' for a wildcard.)

Can we extend the syntax for the match statement from
match_stmt: "match" expression ':' NEWLINE INDENT case_block+ DEDENT
to
match_stmt: "match" expression ['as' NAME] ':' NEWLINE INDENT 
case_block+ DEDENT
with the same meaning as in "with"? 
So the variable with the NAME assumes the value of the expression.

That way I won’t have to use the walrus at every case where I need the full 
result of the expression.
It could even be used to get rid of the walrus_pattern entirely.


Example:

match nested_data[index].attribute as foo:
...
case SomeClass(…):
bar(foo)
…
case AnotherClass(…):
baz(foo)
…
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IJCTESGMZF6NI7ZTSGLRIXLPA7EN4TF2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 mechanical change from:
code.magic_attrname
to:
magicdict[code]

What have I missed?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TDCJFNHIAFEH5NIBEPP2GFP4C2BYR2DP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 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 commenting on these until we've done so:
>> 
>> - Alternative spellings for '|'
>> - Whether to add an 'else' clause (and how to indent it)
>> - A different token for wildcards instead of '_'
>> - What to do about the footgun of 'case foo' vs. 'case .foo'
>> 
>> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to=20
>> mark a variable binding and '?' for a wildcard.)
>> 

We already have 'with' for contexts.


We already have patterns with 'as':
-   except expression "as" identifier ":"
-   "import" module "as" identifier
-   "with"  expression "as" target


So I think this would be quite confusing.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PDVN3D3FCIM34VGNTEUYTFKYPA57B3Z6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 commenting on these until we've done so:
> 
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
> 
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to=20
> mark a variable binding and '?' for a wildcard.)

Can we extend the syntax for the match statement from
match_stmt: "match" expression ':' NEWLINE INDENT case_block+ DEDENT
to
match_stmt: "match" expression ['as' NAME] ':' NEWLINE INDENT 
case_block+ DEDENT
with the same meaning as in "with"? 
So the variable with the NAME assumes the value of the expression.

That way I won’t have to use the walrus at every case where I need the full 
result of the expression.
It could even be used to get rid of the walrus_pattern entirely.


Example:

match nested_data[index].attribute as foo:
...
case SomeClass(…):
bar(foo)
…
case AnotherClass(…):
baz(foo)
…
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N7DWR5ZNF23HSBRPEPP2GWWKQSYM32AM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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
doing here), it will be easier for people to tell who / what you’re
replying to. I wasn’t able to tell what your last few messages were in
reply to.

—Chris


it is just inherently too expensive to ask programs that are already
> dealing with internals and trying to optimize performance to make a
> mechanical change from:
> code.magic_attrname
> to:
> magicdict[code]
>
> What have I missed?
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/TDCJFNHIAFEH5NIBEPP2GFP4C2BYR2DP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DGMTJPPUQ3CJDMHPBL45BIJE2OMLXATG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 doesn’t strike me as sufficient motivation. 

Could the numbers be kept outside the object, perhaps in a weak* dictionary 
that's maintained in the __repr__ method, so you don't pay for it if you don't 
use it? *if the object's hash/eq use identity, anyway... a "weak identity-keyed 
dictionary" might be a nice thing to add anyway
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/I34MYQDLIJNWEHV2JFO4QAKIZKCFTG7A/
Code of Conduct: http://python.org/psf/codeofconduct/