[Numpy-discussion] OpenOpt Suite release 0.45
Wed Apr 10 05:53:59 CDT 2013
On Wed, 2013-04-10 at 11:45 +0200, Sebastian Berg 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.
> 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]
Ah well, so maybe it is not quite as strict, if you know that hashes
can't match (and if they do for another type, equal evaluates to False).
But it would be a bit weird anyway if these give different results.
> 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
> 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
More information about the NumPy-Discussion