Hacker News new | ask | show | jobs
by tachyonbeam 1847 days ago
As an outsider: what was the problem with integer division?
6 comments

Python isn't strongly typed. You got an integer floor operation with -3 / 2 = -2, but -3.2 / 2 = -1.6. This led to errors when floats were expected but integers were possible among your inputs.

In Python 3, it always gives a floating-point result. You can use a floor division operator if you want to round everything (including integers) towards negative infinity.

See https://www.python.org/dev/peps/pep-0238/ for details.

Python is strongly typed, and your examples show the strong (dynamic) type system in action. An example of a language that is not strongly typed would be Javascript, where you can do 1 + "1". In Python, that gets you a typeerror, because Python is strongly typed.
Sorry, you're right, it's strongly typed but it is not statically typed.
In Python 2:

> 20 / 15 = 1

> 20.0 / 15 = 1.3333333333333333

> 20 / 15. = 1.3333333333333333

> 20. / 15. = 1.3333333333333333

In Python 3:

> X / Y is ALWAYS float division

> X // Y is ALWAYS integer division

This was managable in Python 2 but led to lots of float(argument) calls in every function that wanted to do float division. That lead to unnecessary calls, and unnecessary noise in the code.

Python’s separation between ints and floats is quite weak, so it didn’t make sense for `3 / 2` to give a different result from `3.0 / 2` (1 and 1.5 respectively). Python 3 changed the division operator to return 1.5 in both cases.
Unless you come from a programming background where floor behavior is expected for integers, it was strange.

In Python 2: 20 / 15 = 1

In Python 3: 20 / 15 = 1.3333333333333333

To get the old behavior a new operator was added "//"

> Unless you come from a programming background where floor behavior is expected for integers, it was strange.

In all fairness, the C/C++ and Java communities were and are quite substantial.

Of course the rest of us ought to expect 4/3 as the result of 20/15 ;-)

The issue is that `int(x) / int(y)` would yield an int result in Python 2, but a float result in Python 3. So you had to find all the spots in your code where `/` was being used as an integer division operator and replace it with `//`.

Since Python 2 does not have any form of type annotation, this made the task hard to do automatically and error-prone.

Keep in mind that // was added to python in version 2.2a3 along with `from __future__ import division`. This gave everyone almost 7 years to fix up any existing code before the first release of python 3 even happened. 2.7 only got deprecated in 2020, giving developers a total of 18 years to fix their divisions.

I don't know what the PSF should have done to placate people. Keeping a core feature like division confusing like that isn't a good option, and extending support even longer seems ludicrous to me.

I guess they mean python2 1/2 == 0 python3 1/2 == 0.5 (threw me the first time when I moved as I use this to demonstrate the differences in integer devision in C based languages).