D - Python fixes its division design misfeature.
- Ilya Minkov (49/50) Mar 04 2003 It bleeds, but they felt the change was really necessary. I somehow=20
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;" -==20implicit 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.
Mar 04 2003