How Do int and float Behave in Python?

Python gives you three division operators, and the difference between them only becomes obvious with negative numbers, which is exactly where an interview likes to push you.

print(7 / 2)          # 3.5, this is true division
print(7 // 2)         # 3, this is floor division
print(7 % 2)          # 1, this is the remainder

print(-7 / 2)         # -3.5
print(-7 // 2)        # -4, it floors and does not truncate
print(-7 % 2)         # 1, the sign follows the divisor

print(divmod(-7, 2))  # (-4, 1), both results in one call

The single slash always produces a float, even when the operands divide exactly, so 4 / 2 is 2.0 and not 2. The double slash floors the result, and for negative numbers flooring means rounding towards negative infinity. That is why -7 // 2 is -4, while simply cutting off the decimal part would have given -3.

The modulo operator follows the same convention, because the result takes the sign of the divisor, so -7 % 2 is 1 and not -1. That is exactly the behaviour you want when you wrap around the index of a list, because Python's own indexing uses the same rule. my_list[-1] reaches the last element, and the arithmetic stays consistent with it.

divmod is worth remembering because it gives you the quotient and the remainder together. That saves you a division when you need both of them, and it is the standard way to turn a duration into whole hours plus the leftover minutes.

The interview point to make is that Python's modulo is not the modulo that you get in C with negative operands. The C remainder keeps the sign of the value being divided, so -7 % 2 is -1 in C. Getting that difference right is what separates people who have used the language from people who have only read about it.

Python integers grow as large as you need them to. There is no fixed maximum and there is no overflow error, so the only limit is the amount of memory that your machine has.

big = 2 ** 100
print(big)                 # 1267650600228229401496703205376
print(big + 1)             # 1267650600228229401496703205377

# A float is IEEE 754 double precision, so it keeps about 15 to 17 digits.
print(float(2 ** 53) == float(2 ** 53 + 1))   # True, the float rounds
print(2 ** 53 == 2 ** 53 + 1)                 # False, the ints are exact

# A float that overflows becomes infinity instead of raising an error.
print(1e308 * 10)         # inf
print(float('1e400'))     # inf

The first two lines show that 2 to the power of 100 is worked out exactly, and that adding one to it really changes the value instead of being rounded away.

The float lines show the opposite. A double-precision float stores about 53 bits of mantissa, which is roughly 15 to 17 decimal digits, so whole numbers above 2 to the power of 53 cannot all be represented. Notice that the integer comparison is False while the float comparison is True. The integers are exact and the floats are rounded.

The overflow lines are the other asymmetry. A float that goes past the largest value it can hold becomes infinity instead of raising an error, so 1e308 multiplied by 10 prints inf. That behaviour is dangerous in code that calculates a probability or an interest rate, because the wrong answer is produced quietly instead of raising an error that you would notice.

One more thing is worth knowing. The printed digits of a float are the shortest text that reads back as the same value, so 0.1 + 0.2 prints 0.30000000000000004 for a genuine reason, because the binary representation of those two numbers cannot be exact.

Because the two problems are different in their nature, and Python made a different trade-off for each of them. An integer has an exact value, so storing it exactly is simply a matter of using more memory as the number grows, and there is no reason at all to give up precision. A float is defined by the IEEE 754 standard as a 64-bit structure with a 53-bit mantissa, and that format is fixed because it was designed to be carried out in hardware in a fixed number of instructions.

The arbitrary-precision integer came from a deliberate design decision. Python 2 had separate int and long types, and Python 3 merged them into a single int that grows on demand, so the difference between long and int disappeared from the language completely. The cost is that arithmetic on big integers is slower than arithmetic on a machine word and it uses more memory, which is why you would never want to run a hot numeric loop on Python integers.

For money the consequences are severe. A float cannot represent 0.1 exactly in binary, so adding up cents in a float collects error as it goes. A total that should be 19.99 can end up as 19.989999999999998, and repeated addition or repeated multiplication drifts even further. The correct approach is to work in whole units such as cents, or to use the decimal module with its Decimal type created from strings, so that Decimal('0.1') is exactly one tenth.

There is also a rounding trap even when you use the right type, because float arithmetic rounds each individual operation. The error is therefore per step and not only at the end. The interview-safe advice is short. Never use a float for money, never compare two floats for equality, and reach for Decimal or for whole minor units the moment the values are monetary.