proposed language change to int/int==float (was: PEP0238 lament)

Marcin 'Qrczak' Kowalczyk qrczak at knm.org.pl
Sat Jul 28 03:31:00 EDT 2001


28 Jul 2001 14:50:08 +1200, Paul Foley <see at below> pisze:

> No, I know what you're intending, and you're right, it doesn't give
> wrong answers.  The problem is, it doesn't correspond to the type
> graph you draw, either!

Arrows don't mean subtypes but:

1. the direction of implicit conversions needed to perform some
   operations,

2. the fact that any function accepting a (say) rational should accept
   an integer with the same meaning wrt. the mathematical value,
   similarly for other types.

It's not the question of a particular hierarchy but of the meaning of
such diagram at all. It works the same way for all its type relations.
Int is not a "subtype" of rational wrt. your meaning of subtypes.

> *IF* rational is a subtype of float, it *should* be able to turn
> floats into rationals, if they fit.

There are no implicit conversions in this direction in other contexts
either. Rationals never turn into ints in my model for example.

> *IF* rational is a subtype of float, every rational should be
> representable as a float.

My model doesn't claim that these implicit conversions lose no
information. Adding a large int to a float converts the int to
a float which may truncate. It doesn't change the fact that it
makes more sense to perform this lossy conversion than for example
convert both to rationals, because the input float is inexact so
the result will be inexact anyway (that is: its value is not quite
true), so it should be treated as inexact (that is: represented in
a type which is perceived as inexact).

Your diagram doesn't tell how to add a float to a rational at all.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK



More information about the Python-list mailing list