[Numpy-discussion] OpenOpt Suite release 0.45

[Dmitrey]

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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130410/9a5453aa/attachment.html>