• Ilya Minkov (49/50) Mar 04 2003 It bleeds, but they felt the change was really necessary. I somehow=20

Ilya Minkov <midiclub 8ung.at> writes:

It bleeds, but they felt the change was really necessary. I somehow=20
think that you won't regret it if you follow ther decision and introduce =

a *separate* operator for floor division, and make curent "/" produce=20
consistent results with different input types!

---8<---
The most controversial change in Python 2.2 heralds the start of an=20
effort to fix an old design flaw that's been in Python from the=20
beginning. Currently Python's division operator, /, behaves like C's=20
division operator when presented with two integer arguments: it returns=20
an integer result that's truncated down when there would be a fractional =

part. For example, 3/2 is 1, not 1.5, and (-1)/2 is -1, not -0.5. This=20
means that the results of divison can vary unexpectedly depending on the =

type of the two operands and because Python is dynamically typed, it can =

be difficult to determine the possible types of the operands.
--->8---

For some Pro&Contra, see their PEP.
http://www.python.org/peps/pep-0238.html
and explore some links.
They say that the problem is much stronger in Python than in static=20
languages, but consider that D allows for some polymorphism (operator=20
and function overloading, type methods), and thus we are likely to have=20
similar problems. You might know them from C++ as well. Isn't D there to =

fix fundemantal design flaws of C and C++?

Look at Prof. Kahan's papers:
---8<---
Example 3: A programming Joke

Removal of algebraically redundant parentheses corrects a programmer=92s =

mistake:
( Usually, in floating-point expressions, such parentheses are best left =

in place; this is an exception.)
" C=3D(F-32)*(5/9) "  gets the wrong result; can you see why?
" C=3D(F-32)* 5/9  "  gets the right result, converting Fahrenheit F to=20
Celsius C. (See comp.lang.java.help for 1997/07/02 .)

An archaic programming language convention about mixed-type expressions=20
invites that kind of error.

THIS CONVENTION IS A MISTAKE, NOT A JOKE.
--->8---

And consider that making "/" return a real result would raise a type=20
error when assigning if a programmer has made a mistake ("int a=3D2/3;" -=
=20

implicit convertion real->int prohibited), while the current one=20
doesn't, e.g:
real b =3D 2/3;  //b=3D0, which is "OK" in compiler's terms.

It might be also better to define a qotient type, which results from=20
dividing 2 integers (deferring calculation), but gets implicitly=20
converted to float.

This could be solved as an add-on library, if it was possible to=20
overload operators (and methods) on built-in types. This would allow=20
responsible programmers to make their own choice.

-i.