It has nothing about utility, it has to do with what are the possible range of values you're program should/needs to accept.

If it needs to accept both integers and floats as inputs, then you should convert to float since floats can represent the integers.

But if you're program requires that the input be specifically an integer, then you should be casting to int.

EDIT:

In your example, you should always be using float, since money has a decimal value.

If you were asking "How many bananas did you buy?" You'd want to convert to int since those values are going to be 0, 1, 2, 3, 4, .... And then when you ask "How much did you pay for these bananas?" You'd want to convert to float since those inputs can range from 3.15, .77, 1, 1.00, ... etc.

Just compare them directly, there is no harm in that at all.

Python handles comparing numbers of different types perfectly well:

>>> type(1.1)
<class 'float'>
>>> type(1)
<class 'int'>
>>> 1.1 > 1
True
>>> 1.1 < 1
False
>>> 1 < 2
True
>>> 2.2 == 2.2
True
>>> 2 == 2.2
False
>>> 1.6 < 2
True
>>> 1.6 > 2
False
>>> 1.6 == 2
False

Python is duck typed, so in general you shouldn't worry about types directly, just if they can work in the way you need.

There could be some issues with comparing floats for equality with other floats due to precision errors:

>>> 0.3+0.3+0.3 == 0.9
False
>>> 0.3+0.3+0.3
0.8999999999999999

But in comparing to ints and/or < or > operations, you shouldn't worry.

In your update, we can use the decimal module to show the cause:

>>> Decimal(1.2000000000000001)
Decimal('1.20000000000000017763568394002504646778106689453125')
>>> Decimal(1.20000000000000001)
Decimal('1.1999999999999999555910790149937383830547332763671875')

But does this really matter? It's an inherent problem with floating point numbers, but only matters where you need really high precision.

• float stores floating-point values, that is, values that have potential decimal places
• int only stores integral values, that is, whole numbers

So while both are 32 bits wide, their use (and representation) is quite different. You cannot store 3.141 in an integer, but you can in a float.

Dissecting them both a little further:

In an integer, all bits except the leftmost one are used to store the number value. This is (in Java and many computers too) done in the so-called two's complement, which support negatives values. Two's complement uses the leftmost bit to store the positive (0) or negative sign (1). This basically means that you can represent the values of −2³¹ to 2³¹ − 1.

In a float, those 32 bits are divided between three distinct parts: The sign bit, the exponent and the mantissa. They are laid out as follows:

S EEEEEEEE MMMMMMMMMMMMMMMMMMMMMMM

There is a single bit that determines whether the number is negative or non-negative (zero is neither positive nor negative, but has the sign bit set to zero). Then there are eight bits of an exponent and 23 bits of mantissa. To get a useful number from that, (roughly) the following calculation is performed:

M × 2^E

(There is more to it, but this should suffice for the purpose of this discussion)

The mantissa is in essence not much more than a 24-bit integer number. This gets multiplied by 2 to the power of the exponent part, which, roughly, is a number between −128 and 127.

Therefore you can accurately represent all numbers that would fit in a 24-bit integer but the numeric range is also much greater as larger exponents allow for larger values. For example, the maximum value for a float is around 3.4 × 10³⁸ whereas int only allows values up to 2.1 × 10⁹.

But that also means, since 32 bits only have 4.2 × 10⁹ different states (which are all used to represent the values int can store), that at the larger end of float's numeric range the numbers are spaced wider apart (since there cannot be more unique float numbers than there are unique int numbers). You cannot represent some numbers exactly, then. For example, the number 2 × 10¹² has a representation in float of 1,999,999,991,808. That might be close to 2,000,000,000,000 but it's not exact. Likewise, adding 1 to that number does not change it because 1 is too small to make a difference in the larger scales float is using there.

Similarly, you can also represent very small numbers (between 0 and 1) in a float but regardless of whether the numbers are very large or very small, float only has a precision of around 6 or 7 decimal digits. If you have large numbers those digits are at the start of the number (e.g. 4.51534 × 10³⁵, which is nothing more than 451534 follows by 30 zeroes – and float cannot tell anything useful about whether those 30 digits are actually zeroes or something else), for very small numbers (e.g. 3.14159 × 10⁻²⁷) they are at the far end of the number, way beyond the starting digits of 0.0000...

Floating point numbers are approximations in many cases. Some integers (and decimals) can be exactly represented by a float, but most can't. See Floating Point Arithmetic: Issues and Limitations.

>>> a = 1000000000000000000000000000
>>> a+1 == a
False
>>> a = 1000000000000000000000000000.0
>>> a+1 == a
True

Resulting from this approximative nature of floats, some calculations may yield unexpected results (this isn't directly pertinent to the question, but it illustrates the point quite well):

>>> sum(1.1 for _ in range(9))
9.899999999999999

For example, when you're dealing with money calculations, it's better to use integers, or (if speed is not an issue) the decimal module.