You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
iirc memorystore instances get a repr based on the memory location of the underlying dictionary. Any code example that creates a memorystore will generate different output each invocation as the name of the store will change, which is a problem for documentation, as the same example will generate different output. So it would be convenient to give memorystore instances names that are unique but deterministic (within a single python process).
I had 2 ideas:
Generate names from a global counter that increments each time a memorystore is created. So the first, second, ... nth memory store created would always have the same name across executions of the same program.
Allow users to provide a display_name kwarg to memorystore creation. The name does nothing except show up in the repr.
which is a problem for documentation, as the same example will generate different output
Is the problem there general confusion for users, or something else (like doctests)? For doctests, we can use ... in place of the memory address.
For general confusion, I guess this did hit me when I was first learning python. But I think there's enough other objects out there that contain a hex memory address that maybe people learn? Not sure.
I'm not sure if users find this confusing, but I think it's worth asking whether the memory address is a useful property to display for memory store instances. Unlike an s3 bucket or location on the local file system, a memory address for a python object is kind of useless. So I don't think anyone would be inconvenienced if we replaced that repr with something equally useless, but deterministic.
One key feature of showing the memory address is being able to tell if two memory stores are the same or different. So in that sense yes, showing the memory address is useful. And it seems to me to be the simplest way in terms of implementation of generating a "unique ID" for the store, which statisfies the contstraint that different store instances have different reprs.
One key feature of showing the memory address is being able to tell if two memory stores are the same or different.
to be clear, I'm assuming that memory store instances should have unique names. The question in this issue is whether the memory address of the underlying mutable mapping is a good name, compared to an alternative name that would also be unique, but deterministic.
Activity
TomAugspurger commentedon Mar 12, 2025
Is the problem there general confusion for users, or something else (like doctests)? For doctests, we can use
...in place of the memory address.For general confusion, I guess this did hit me when I was first learning python. But I think there's enough other objects out there that contain a hex memory address that maybe people learn? Not sure.
d-v-b commentedon Mar 12, 2025
I'm not sure if users find this confusing, but I think it's worth asking whether the memory address is a useful property to display for memory store instances. Unlike an s3 bucket or location on the local file system, a memory address for a python object is kind of useless. So I don't think anyone would be inconvenienced if we replaced that repr with something equally useless, but deterministic.
dstansby commentedon Mar 17, 2025
One key feature of showing the memory address is being able to tell if two memory stores are the same or different. So in that sense yes, showing the memory address is useful. And it seems to me to be the simplest way in terms of implementation of generating a "unique ID" for the store, which statisfies the contstraint that different store instances have different reprs.
dcherian commentedon Mar 17, 2025
👍 I have relied on this in the past. It's pretty standard to show the address in the default Python repr too.
d-v-b commentedon Mar 18, 2025
to be clear, I'm assuming that memory store instances should have unique names. The question in this issue is whether the memory address of the underlying mutable mapping is a good name, compared to an alternative name that would also be unique, but deterministic.