<html>
<body>


<span class="xfm_404392373"><span><div style="height: 1px;">      </div> <br/><br/><div style="font-size: 14px; font-style: italic;"> ---   ---<br/>  : "Alan G Isaac" <<a href="mailto:alan.isaac@gmail.com"  target="_self">alan.isaac@gmail.com</a>><br/>  : 10  2013, 15:12:07<br/></div> <br/><blockquote class="xfmc0" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;"><pre>On 4/10/2013 3:31 AM, Robert Kern wrote:
> 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.



Hi Dmitrey,

Robert and Sebastien have taken their time to carefully explain
to your why your design is flawed.  Your response has been only
that you rely on this design flaw and it has not bitten you yet.<br/></pre></blockquote>It had bitten me some times till I understood the bugs source, but as I had mentioned I had fixed all those parts of code.<br/><pre><br/></pre><blockquote class="xfmc0" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;"><pre>I trust you can see that this is truly not a response.

The right response is to explore how you can refactor to
eliminate this lurking bug, or to prove that it can *never*
bite due to another design feature.  You have done neither,
and the second looks impossible.  So you have work to do.<br/></pre></blockquote><br/><blockquote class="xfmc0" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;"><pre>You say that you *must* use oofuns as dict keys.  This is probably
false, but you clearly want to retain this aspect of your design.
But this choice has an implication for the design of oofuns,
as carefully explained in this thread.  So you will have to
change the design, even though that may prove painful.<br/></pre></blockquote>Refactoring is mere impossible, user API and thouzands lines of whole FuncDesigner kernel heavily relies on the oofuns as dict keys. Also, I don't see any alternative that is as convenient and fast as the involved approach.<br/>As for new features, I just keep it in mind while implementing them, and now it's quite simple. <br/><br/><blockquote class="xfmc0" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;"><pre>No smaller step is adequate to the quality of software you
aspire to.

One last thing.  When someone like Robert or Sebastien take their
time to explain a problem to you, the right response is "thank you",
even if their news is unwelcome.  Don't shoot the messenger.<br/></pre></blockquote>I understand your opinion, but I'm not a kind of person who thanks on responses like "Well, it's your software. You are free to make it as buggy as you wish" (Robert have apologised, although). <br/>Also, I haven't thanked Sebastien because I was AFK. <br/>Thanks for all who participated in the thread.<br/>D.<br/><br/></span></span>

</body>
</html>