On Sat, Mar 16, 2013 at 10:39 AM, Matthieu Brucher
<matthieu.brucher@gmail.com> wrote:
> Even if they have different hashes, they can be stored in the same
> underlying list before they are retrieved. Then, an actual comparison is
> done to check if the given key (i.e. object instance, not hash) is the same
> as one of the stored keys.
Right. And the rule is that if two objects compare equal, then they
must also hash equal. Unfortunately, it looks like `oofun` objects do
not obey this property. oofun.__eq__() seems to return a Constraint
rather than a bool, so oofun objects should simply not be used as
dictionary keys.
It is one of several base features FuncDesigner is build on and is used extremely often and wide; then whole FuncDesigner would work incorrectly while it is used intensively and solves many problems better than its competitors.That's quite possibly the source of the bug. Or at
least, that's a bug that needs to get fixed first before attempting to
debug anything else or attribute bugs to Python or numpy. Also, the
lack of a bool-returning __eq__() will prevent proper sorting, which
also seems to be used in the code snippet that Dmitrey showed.
as I have already mentioned, I ensured via debugger that my __eq__, __le__ etc are not involved from the buggy place of the code, only __hash__ is involved from there.