www.digitalmars.com         C & C++   DMDScript  

D - Python fixes its division design misfeature.

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!

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.

For some Pro&Contra, see their PEP.
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:
Example 3: A programming Joke

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

( 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.


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;" -=
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.
Mar 04 2003