PEP0238 lament

[Marcin 'Qrczak' Kowalczyk]

Mon, 23 Jul 2001 18:45:12 GMT, Grant Edwards <grante at visi.com> pisze:

>>But ints *are* implicitly converted to floats when needed
> 
> Language design mistake.

It allows to write code which increments a number of unknown type
by one. How would you write it in your universe?

It can be written in Python 2.2 changed to disallow implicit
conversions:
    def add_one(x):
        return x + type(x)(1)
but I'm not convinced that we should require this style.

Your view is practical as long as you can convert to a type
depending on the context or write literals having a type depending
on the context. This is how Haskell works, where (+) only works for
arguments of the same type, and in x+1 the 1 denotes an Integer if
x is an Integer, a Double if x is a Double, a Rational if x is a
Rational etc., and (+) is overloaded likewise.

It can't be adapted for Python because it doesn't have static types
and the meaning of an expression can't depend on how it will be used.
So it uses implicit conversions instead: although 2 isn't already
a float or rational, it can be used as such if needed. This works too.

BTW, in Haskell 1/2 can be a Rational or Double or any numeric type
which supports fractions, which doesn't include Integer. Integer
division is spelled div (as a function) or `div` (as an operator).
Haskell could choose to overload (/), to let it mean one thing for
Integers and another for Doubles. But it didn't do that. Actually
there is no builtin type which has both (/) and div defined. And it
provides both div+mod and quot+rem. Explicit is better than implicit.

I know no language which doesn't do implicit conversions from integer
to float *and* doesn't signal this error at compile time. There are
only languages like OCaml with completely disjoint integer and float
arithmetic, with separate literals and separate operators.

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