Closed klauer closed 2 years ago
A thought here: Typically you only want to hash immutable objects, lest their hashes change and they get lost in the hash table somewhere. The use case we are considering right now (finding intersections of sets of SearchResult
s) is innocuous enough, but a SearchResult
is very much a mutable object.
Perhaps it shouldn't be though. If we're modifying a search result before instantiating an object or something similar, there's a problem
I think SearchResult
isn't really intentionally mutable - just it has a dictionary of metadata that you could come along and modify if you so pleased.
Since each result pairs with a given identifier from the database, the hash key of a SearchResult
could be something like (client, metadata["_id"])
I have a working implementation that bases the hash on the metadata dictionary, which I was considering making a frozendict
to alleviate my mutability concerns. I figure if we don't intend the object to be mutable we may as well force it to be as such.
For some reason I thought there was a frozendict
in the standard library. I suppose we leave this be then
_Originally posted by @klauer in https://github.com/pcdshub/happi/pull/254#discussion_r888369082_