An easy solution to all of this is to use a dict-like object that matches keys based on object identity while ignoring __hash__ and __eq__ entirely, e.g.:
https://bitbucket.org/pypy/pypy/src/2f51f2142f7b/lib_pypy/identity_dict.py#cl-9 -n On Wed, Apr 10, 2013 at 10:45 AM, Sebastian Berg <sebast...@sipsolutions.net> wrote: > On Wed, 2013-04-10 at 11:54 +0300, Dmitrey wrote: >> On 04/10/2013 10:31 AM, Robert Kern wrote: >> > You think comparing tracked bug counts across different projects >> > means anything? That's adorable. I admire your diligence at >> > addressing the bugs that you do acknowledge. That was never in >> > question. But refusing to acknowledge a bug is not the same thing as >> > fixing a bug. You cannot use objects that do not have a valid >> > __eq__() (as in, returns boolean True if and only if they are to be >> > considered equivalent for the purpose of dictionary lookup, >> > otherwise returns False) as dictionary keys. Your oofun object still >> > violates this principle. As dictionary keys, you want them to use >> > their `id` attributes to distinguish them, but their __eq__() method >> > still just returns another oofun with the default >> > object.__nonzero__() implementation. This means that bool(some_oofun >> > == other_oofun) is always True regardless of the `id` attributes. >> > You have been unfortunate enough to not run into cases where this >> > causes a problem yet, but the bug is still there, lurking, waiting >> > for a chance hash collision to silently give you wrong results. That >> > is the worst kind of bug. -- Robert Kern >> I had encountered the bugs with bool(some_oofun == other_oofun) when >> it was raised from other, than dict, cases, e.g. from "in list" (e.f. >> "if my_oofun in freeVarsList") etc, and had fixed them all. But that >> one doesn't occur from "in dict", I traced it with both debugger and >> putting print("in __eq__"),print("in __le__"), print("in __lt__"), >> print('in __gt__'), print('in __ge__') statements. > > This is all good and nice, but Robert is still right. For dictionaries > to work predictable you need to ensure two things. > > First: > > if object1 == object2: > assert bool(hash(object1) == hash(object2)) > > and second, which is your case for the dictionary lookup to be > predictable this must always work: > > keys, values = zip(*dictionary.keys()) > assert(keys.count(object2) == 1) > > index = keys.index(object2) > value = values[index] > > And apparently this is not the case and it simply invites bugs which are > impossible to track down because you will not see them in small tests. > Instead you will have code that runs great for toy problems and can > suddenly break down in impossible to understand ways when you have large > problems. > > So hopefully the list fixes you mention provide that the second code > block will work as you would expect dictionary[object2] to work, but if > this is not the case... > > - Sebastian > >> As I had mentioned, removing mapping oofuns as dict keys is mere >> impossible - this is fundamental thing whole FuncDesigner is build on, >> as well as its user API. >> D. >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion