[Python-ideas] [Python-Dev] The Case Against Floating Point ==

[Mark Dickinson]

On Tue, Mar 18, 2008 at 6:33 PM, Jim Jewett <jimjjewett at gmail.com> wrote:
>
>  They sort of already did -- you can define __eq__ and __ne__ on your
>  own class in bizarre and inconsistent ways.  [Though I think you can't
>  easily override that (x is y) ==> (x==y).]

Why not?  I get this with Python 2.5.1:

>>> from decimal import *
>>> Decimal.__eq__ = lambda x, y: False
>>> x = Decimal(2)
>>> x == x
False
>>> x is x
True
>>>

Or am I misunderstanding your meaning?

<unnecessary pendantry> Of course, even for floats it's not true
that x is y implies x == y:

>>> x = float('nan')
>>> x is x
True
>>> x == x
False

</unnecessary pedantry>

>  Changing an existing class requires that the class be "open".  That is
>  the default in languages like smalltalk or ruby.  It is even the
>  default for python classes -- but it is certainly not the default for
>  "python" classes that are actually coded in C -- which includes
>  floats.

You mean like:

>>> float.__eq__ = lambda x, y: False
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't set attributes of built-in/extension type 'float'

?  Presumably there are good reasons for this restriction
(performance? convenience? lack of round tuits?), but
I've no idea what they are.  I can't say that I've ever felt a
need to do anything like this.

Mark