It bleeds, but they felt the change was really necessary. I somehow think that you won't regret it if you follow ther decision and introduce a *separate* operator for floor division, and make curent "/" produce consistent results with different input types!

---8<---
The most controversial change in Python 2.2 heralds the start of an effort to fix an old design flaw that's been in Python from the beginning. Currently Python's division operator, /, behaves like C's division operator when presented with two integer arguments: it returns 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 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 languages, but consider that D allows for some polymorphism (operator and function overloading, type methods), and thus we are likely to have 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’s mistake:
( Usually, in floating-point expressions, such parentheses are best left in place; this is an exception.)
" C=(F-32)*(5/9) "  gets the wrong result; can you see why?
" C=(F-32)* 5/9  "  gets the right result, converting Fahrenheit F to Celsius C. (See comp.lang.java.help for 1997/07/02 .)

An archaic programming language convention about mixed-type expressions 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 error when assigning if a programmer has made a mistake ("int a=2/3;" -> implicit convertion real->int prohibited), while the current one doesn't, e.g:
real b = 2/3;  //b=0, which is "OK" in compiler's terms.

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

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

-i.