=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin@v.loewis.de> wrote:
If so, they just shouldn't use the equal operator (==). == ought to
be transitive. It should be consistent with has().
Fine. A very valid viewpoint. Would you like to explain that to
the IEEE 754 people?
Why should I? I don't talk about IEEE 754, I talk about Python.
The problem is that Python is increasingly assuming IEEE 754 by
implication, and you were stating something as a requirement that
isn't true in IEEE 754.
Strictly, it is only the reflexive property that IEEE 754 and the
Decimal module lack. Yes, A == A is False, if A is a NaN. But
the definition of 'transitive' often requires 'reflexive'.
I deliberately stated 'transitive', not 'reflexive'. The standard
definition of 'transitive' is "if a==b and b==c then a==c".
When I was taught mathematics, the lecturer said that a transitive
relation is a reflexive one that has that extra property. It was
then (and may still be) a fairly common usage. I apologise for being
confusing!
The most common form was where comparison was equivalent to subtraction,
and there were numbers such that A-B == 0, B-C == 0 but A-C != 0. That
could occur even for integers on some systems. I don't THINK that the
Decimal specification has reintroduced this, but am not quite sure.
I'm not talking about subtraction, either. I'm talking about == and
hash.
Grrk. Look again. So am I. But let this one pass, as I don't think
that mistake will return - and I sincerely hope not!
Fine. Again, a very valid viewpoint. Would you like to explain it
to the IEEE 754, Decimal and C99 people, and the Python people who
think that tracking C is a good idea?
I'm not explaining anything. I'm stating an opinion.
You are, however, stating an opinion that conflicts with the direction
that Python is currently taking.
It doesn't look like you *need* to give an answer now. I thought
you were proposing some change to Python (although I'm uncertain
what that change could have been). If you are merely explaining
things (to whom?), just keep going.
Thanks. I hope the above clarifies things a bit. My purpose in
posting is to point out that some changes are already happening,
by inclusion from other standards, that are introducing problems
to Python. And to many other languages, incidentally, including
Fortran and C.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Nick Maclaren