> The classic division operator makes it hard [in a dynamic language like Python] to write numerical expressions that are supposed to give correct results from arbitrary numerical inputs ... Another way to look at this is that classic division makes it difficult to write polymorphic functions that work well with either float or int arguments; all other operators already do the right thing. No algorithm that works for both ints and floats has a need for truncating division in one case and true division in the other.
In Python 2.0, this is incorrect, unless you could guarantee that at least one of distance and time was not a integer. The correct solution is something like:
while other valid-seeming solutions are subtly broken:
x = float(x) # Broken if x is complex
x = x+0.0 # Broken if x is -0.0
Why you would pass in a complex number, I've no idea. But perhaps the imaginary component is 0?
>>> 50/(30+0j)
(1.6666666666666667+0j)
In C this isn't a problem because the "double distance" and "double time" in the argument list ensure the algorithm is dealing with doubles.
In addition, though the PEP doesn't say it, there's some influence from the Alice programming language, which started in the 1990s and built on Python. Quoting "Alice: Lessons Learned from Building a 3D System For Novices" at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.43.... :
> Although we resisted changing the Python implementation, our user testing data forced us to make two changes. First, we modified Python’s integer division, so users could type 1/2 and have it evaluate to 0.5, rather than zero. Second, we made Python case insensitive. Over 85% of our users made case errors and many continued to do so even after learning that case was significant.
Feedback from Alice helped influence van Rossum's decision for changing division. As for "Case Insensitivity", see slide 44 from the OSCON presentation, with that as the title and "[ducks :-]" as the sole content.
