I'm not sure if I understand what you mean by Python having trouble with really large floats. If what you mean is that floating-point numbers can't represent every integer, and that you get appearently surprising results like,

>>> float(2**53)+1.0 == float(2**53)
True

then that is just how floating-point numbers work in all programming languages.

Anyway, floating-point arithmetic is not the reason why python raises an error. Indexing a list or string using fractional numbers (floats) just don't make sense and therefore python raises an error instead of doing something potentially surprising or wrong.

Example:

>>> l = [1,2,3]
>>> l[1.2] 
Traceback (most recent call last):
  File "<input>", line 1, in <module>
    l[1.2]
TypeError: list indices must be integers or slices, not float

This is me being pedantic, but xrange is removed in Python 3, not deprecated.

I have had problems getting my solution in python to work on the random inputs, i.e. it sometimes works and sometimes doesn't.
After having disected your one-line solution I have found that it gives wrong answers for input where both numbers have 9 at the same digit place and the previous digits gave a carry.

For example
"95 96" should obviously have 2 carry operations but your solution outputs 1.

Is this the bug you are talking about?

This wrong solution is used to validate submitted solutions for random input. This means that the tests will only pass if one is "lucky" enough to not get an input of the form described above.

Added now.

Yes, you're right. Determining if a list is sorted by sorting it isn't the best way to do it.