4 ms·

As an outsider: what was the problem with integer division?

AnIdiotOnTheNet 5y ago
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 "//"
- guenthert 5y ago
  > 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 ;-)
pansa2 5y ago
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.
LeifCarrotson 5y ago
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/ https://www.python.org/dev/peps/pep-0238/ for details.
- leephillips 5y ago
  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.
  - LeifCarrotson 5y ago
    Sorry, you're right, it's strongly typed but it is not statically typed.
loa_in_ 5y ago
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.
HerrMonnezza 5y ago
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.
- Doxin 5y ago
  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.
jpm48 5y ago
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).

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 "//"

guenthert 5y ago
> 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 ;-)

pansa2 5y ago

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.

LeifCarrotson 5y ago

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/ https://www.python.org/dev/peps/pep-0238/ for details.

leephillips 5y ago
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.
- LeifCarrotson 5y ago
  Sorry, you're right, it's strongly typed but it is not statically typed.

loa_in_ 5y ago

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.

HerrMonnezza 5y ago

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.

Doxin 5y ago
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.

jpm48 5y ago

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