Hi, Yes, there are several options, but they all involve an extra layer that detracts between the interface I am building and my user's code. In this situation, the objects being used as keys are conceptually the unique entities that the user deals with, even if their data is non-unique. And I do not want to subject the user to the un-pythonic use of some operator other than '==' to determine their equivalence.
As near as I can tell, returning the id() in __hash__() results in a perfect hash key. I really want to know if that is true. Because if it is true, any further layer is simply covering for a failing in the documentation. Thanks! On Sun, Oct 27, 2019 at 4:54 AM Random832 <random...@fastmail.com> wrote: > > On Sat, Oct 19, 2019, at 07:31, Steve White wrote: > > Hi, > > > > I have an application that would benefit from object instances > > distinguished by identity being used in dict's and set's. To do this, > > the __hash__ method must be overridden, the obvious return value being > > the instance's id. > > > > This works flawlessly in extensive tests on several platforms, and on > > a couple of different Python versions and implementations. > > > > The documentation seems to preclude a second requirement, however. > > > > I also want to use the == operator on these objects to mean a natural > > comparison of values, different from identity, so that two instances > > comparing equivalent does not imply that they are identical. > > I'd like to jump in to this thread to note that while this is reasonably > easily achieved with a custom mapping class that uses a dict along with a > wrapper class that stores the identity... > > I once tried to make a WeakKeyDictionary that was keyed by identity and had > no end of trouble. > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
