[Python-Dev] Python's C interface for types

[Nick Maclaren]

=?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