PEP0238 lament

[Marcin 'Qrczak' Kowalczyk]

23 Jul 2001 10:47:08 GMT, Martijn Faassen <m.faassen at vet.uu.nl> pisze:

> "+" does two different things depending on what you pass in (strings or
> numbers). "*" does so too. They both can be said to lose information.

The difference between '+' and '/' is that ints aren't implicitly
converted to strings, so one wouldn't use an int instead of a string
expecting '+' to do the conversion and concatenation. But ints *are*
implicitly converted to floats when needed in about all contexts except
'/', so it would be reasonable to expect them to be converted in the
'/' case too.

In languages where ints are implicitly converted to strings, addition
and concatenation are typically different operators. Like in Perl:
'+' and '.'.

Python does treat ints and floats as different parts of the same
concept by letting them compare equal and convert as needed. So real
division and integer division should be distinguished by the operator.

To help with migration there can be old_div(x,y) function. That way
old / can be unconditionally replaced with old_div for a quick fix,
and it can be made nicer by saying explicitly which division is meant
when somebody has time to do it properly.

I still favor 'x div y' and 'x mod y', with '/' on ints giving
rationals, and with mixed rationals with floats giving floats.
Literals like 1.2 would continue to mean floats, so each type has
nicely spelled constants:
    7    -  int (unified with long in the future)
    7/3  -  rational
    7.2  -  float

Each time a float is expected, a rational would give the same answer
(perhaps in a different type or accuracy). Each time a rational
is expected, an integer would give the same answer (perhaps in
a different type).

'"%.02f" % a_rational' is a good way to output currency amounts.
'rational(a_string)' is a good way to input them.

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