Python Language Incompatibilities moving from Python 2 to Python 3 Integer Division
Example
The standard division symbol (/) operates differently in Python 3 and Python 2 when applied to integers.
When dividing an integer by another integer in Python 3, the division operation x / y represents a true division (uses __truediv__ method) and produces a floating point result. Meanwhile, the same operation in Python 2 represents a classic division that rounds the result down toward negative infinity (also known as taking the floor).
For example:
| Code | Python 2 output | Python 3 output |
|---|---|---|
3 / 2 | 1 | 1.5 |
2 / 3 | 0 | 0.6666666666666666 |
-3 / 2 | -2 | -1.5 |
The rounding-towards-zero behavior was deprecated in Python 2.2, but remains in Python 2.7 for the sake of backward compatibility and was removed in Python 3.
Note: To get a float result in Python 2 (without floor rounding) we can specify one of the operands with the decimal point. The above example of 2/3 which gives 0 in Python 2 shall be used as 2 / 3.0 or 2.0 / 3 or 2.0/3.0 to get 0.6666666666666666
| Code | Python 2 output | Python 3 output |
|---|---|---|
3.0 / 2.0 | 1.5 | 1.5 |
2 / 3.0 | 0.6666666666666666 | 0.6666666666666666 |
-3.0 / 2 | -1.5 | -1.5 |
There is also the floor division operator (//), which works the same way in both versions: it rounds down to the nearest integer. (although a float is returned when used with floats) In both versions the // operator maps to __floordiv__.
| Code | Python 2 output | Python 3 output |
|---|---|---|
3 // 2 | 1 | 1 |
2 // 3 | 0 | 0 |
-3 // 2 | -2 | -2 |
3.0 // 2.0 | 1.0 | 1.0 |
2.0 // 3 | 0.0 | 0.0 |
-3 // 2.0 | -2.0 | -2.0 |
One can explicitly enforce true division or floor division using native functions in the operator module:
from operator import truediv, floordiv
assert truediv(10, 8) == 1.25 # equivalent to `/` in Python 3
assert floordiv(10, 8) == 1 # equivalent to `//`
While clear and explicit, using operator functions for every division can be tedious. Changing the behavior of the / operator will often be preferred. A common practice is to eliminate typical division behavior by adding from __future__ import division as the first statement in each module:
# needs to be the first statement in a module
from __future__ import division
| Code | Python 2 output | Python 3 output |
|---|---|---|
3 / 2 | 1.5 | 1.5 |
2 / 3 | 0.6666666666666666 | 0.6666666666666666 |
-3 / 2 | -1.5 | -1.5 |
from __future__ import division guarantees that the / operator represents true division and only within the modules that contain the __future__ import, so there are no compelling reasons for not enabling it in all new modules.
Note: Some other programming languages use rounding toward zero (truncation) rather than rounding down toward negative infinity as Python does (i.e. in those languages -3 / 2 == -1). This behavior may create confusion when porting or comparing code.
Note on float operands: As an alternative to from __future__ import division, one could use the usual division symbol / and ensure that at least one of the operands is a float: 3 / 2.0 == 1.5. However, this can be considered bad practice. It is just too easy to write average = sum(items) / len(items) and forget to cast one of the arguments to float. Moreover, such cases may frequently evade notice during testing, e.g., if you test on an array containing floats but receive an array of ints in production. Additionally, if the same code is used in Python 3, programs that expect 3 / 2 == 1 to be True will not work correctly.
See PEP 238 for more detailed rationale why the division operator was changed in Python 3 and why old-style division should be avoided.
See the Simple Math topic for more about division.
