[Numpy-discussion] OpenOpt Suite release 0.45

[Nathaniel Smith]

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
<sebastian at 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 at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion