<div class="gmail_quote">On Thu, Mar 13, 2008 at 6:18 PM, Imri Goldberg <<a href="mailto:lorgandon@gmail.com">lorgandon@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">This makes changing == behavior to an epsilon comparison more involved.<br></div>
I still think it is feasible, but will require much more consideration.<br></blockquote><div><br class="webkit-block-placeholder"></div><div>Okay, now I am going to be negative. :-)</div><div><br class="webkit-block-placeholder">
</div><div>I really think that there's essentially zero chance of == and != ever changing</div><div>to 'fuzzy' comparisons in Python.  I don't want to discourage you from working</div><div>out possible details as an academic exercise, or perhaps with some other</div>
<div>(Python-like?) language in mind, but I just don't see it ever happening in Python.</div><div>Maybe I'm wrong, in which case I hope other python people will tell me so,</div><div>but I think pursuing this is, in the end, going to be a waste of time.</div>
<div><br class="webkit-block-placeholder"></div><div>Some reasons, and then I'll shut up:</div><div><br class="webkit-block-placeholder"></div><div>Too much complication and magic implicit stuff going on</div><div>behind the scenes.  In a fuzzy a == b there are hidden choices about the</div>
<div>fuzziness scheme and the amount of fuzz to allow, and those choices</div><div>are going to confuse the hell out of newbie and expert programmers alike.</div><div><br class="webkit-block-placeholder"></div><div>As above, you'd have to choose defaults for the fuzziness, and by Murphy's</div>
<div>Law those defaults would be wrong for almost everybody else's particular</div><div>applications, meaning that almost everybody else would have to go away</div><div>and learn about how to change or turn off the fuzziness.</div>
<div><br class="webkit-block-placeholder"></div><div>Fundamental and well-understood laws (trichotomy, transitivity of equality)</div><div>would break.  It's really unclear how the other comparison operators</div><div>
would be affected.  If 1.0 == 1.0+2e-16 returns True, shouldn't</div><div>1.0 >= 1.0+2e-16 also return True?</div><div><br class="webkit-block-placeholder"></div><div>Containers would be affected in peculiar ways.  I think people would be</div>
<div>really surprised to find that 1.0+2e-16 *was* an element of the set {1.0},</div><div>or that 1.0 and 1.0+2e-16 weren't allowed to be different keys in a dict.</div><div>And how on earth do you check for set or dict membership under the </div>
<div>hood?</div><div><br class="webkit-block-placeholder"></div><div>I don't know of any other language that has successfully done this, even</div><div>though I've seen the idea floated many times for different languages.</div>
<div>That doesn't mean much, since I only know a small handful of the many</div><div>hundreds (thousands?) of languages out there.  If you know a</div><div>counterexample, I'd be interested to hear it.</div><div><br class="webkit-block-placeholder">
</div><div>Mark</div></div>