[Python-Dev] Python's C interface for types (original) (raw)

Nick Maclaren nmm1 at cus.cam.ac.uk
Thu Feb 1 21:24:57 CET 2007

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin at 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 at cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

More information about the Python-Dev mailing list