Rich Comparisons Gotcha

[Mark Dickinson]

On Dec 8, 2:24 pm, Rasmus Fogh <rh... at mole.bio.cam.ac.uk> wrote:

> So, I would much prefer a language change. I am not competent to even
> propose one properly, but I'll try.

I don't see any technical problems in what you propose:  as
far as I can see it's entirely feasible.  However:

> should. On the minus side there would be the difference between
> '__equal__' and '__eq__' to confuse people.

I think this is exactly what makes the idea a non-starter. There
are already enough questions on the lists about when to use 'is'
and when to use '==', without adding an 'equals' function into
the mix.  It would add significant extra complexity to the core
language, for questionable (IMO) gain.


There are certainly other languages for which this distinction
would make sense;  I just don't think it's appropriate
for Python, with its emphasis on practicality and and
simplicity.

Mark



 On the plus side the behaviour
> of objects inside collections would now be explicitly defined, and __eq__
> and __equal__ would be so similar that most people could ignore the
> distinction.
>
> Some examples:
>
> # NaN:
> # For floats, __equal__ would be the same as __eq__. For NaN this gives>>> x = float('NaN')
> >>> y = float('NaN')
> >>> x == x
> False
> >>> equal(x,x)
> True
> >>> equal(x,y)
>
> False
> # It may be problematical mathematically, but computationally it makes
> # perfect sense that looking in a given storage location will give you the
> # same value every time, even if the actual value happens to be undefined.
> # The behaviour is simple to describe, and indeed NaN does behave this way
> # in collections at the moment. All we are doing is documenting it clearly.
>
> # numpy
> Numpy would have no __equal__ function, so we would have pure identity
> semantics - 'equals(x,y)' would be the same as 'x is y'
>
> # ordinary numbers.
> Any Python object with value semantics would need an __equal__ function
> with the correct behaviour.
> Mark Dickinson pointed out the thread "Comparing float and decimal", which
> shows that comparisons between float and decimal numbers do not currently
> satisfy 3). It would not be attractive to have __equal__ and __eq__ behave
> differently for ordinary numbers, so if the relevant __eq__ can not be
> fixed that is a problem for my proposal.
>
> At this point I shall try to retire gracefully. Regrettably I am not
> competent to discuss if this can be done, how it can be done, and how
> much work is required.
>
> Rasmus
>
> ---------------------------------------------------------------------------
> Dr. Rasmus H. Fogh                  Email: r.h.f... at bioc.cam.ac.uk
> Dept. of Biochemistry, University of Cambridge,
> 80 Tennis Court Road, Cambridge CB2 1GA, UK.     FAX (01223)766002