Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deterministic memorystore names #2906

Open
d-v-b opened this issue Mar 12, 2025 · 5 comments
Open

deterministic memorystore names #2906

d-v-b opened this issue Mar 12, 2025 · 5 comments

Comments

@d-v-b
Copy link
Contributor

d-v-b commented Mar 12, 2025

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.

Does anyone else have ideas here?

@TomAugspurger
Copy link
Contributor

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.

@d-v-b
Copy link
Contributor Author

d-v-b commented 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
Copy link
Contributor

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
Copy link
Contributor

One key feature of showing the memory address is being able to tell if two memory stores are the same or different.

👍 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
Copy link
Contributor Author

d-v-b commented Mar 18, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants