Increased accurate in regards to recording proper delays between act…

[ra314]

…ions.

#37 (comment)

[RMPR]

Awesome work, can you have a look at the suggested changes?

[ra314]

Thanks.
I applied the changes.
Just curious, were the changes purely for readability purposes.
i.e to make it clear that timeout is a flaot?
Cause these lines are otherwise equivalent right?

[RMPR]

These lines might be equivalent to the user, but for the Python interpreter they are not because comparison is a pain.

timeout >= 0 is equivalent to timeout.__gt__(0)

Now, you need to consider two things:

• When you explicitly convert 0 to 0.0, the comparison is done as straightforwardly (and long-windedly) as conceivable. It's done so that, e.g., Python x == y delivers the same result as the platform C x == y.

• When you don't explicitly convert into to a float before the comparison: __gt__ needs to handle the conversion to float first (not as straightforward as one may think at first) then make the comparison.

The maintainers say it much better than I ever could:

When mixing float with an integer type, there's no good uniform approach. Converting the double to an integer obviously doesn't work, since we may lose info from fractional bits. Converting the integer to a double also has two failure modes: (1) an int may trigger overflow (too large to fit in the dynamic range of a C double); (2) even a C long may have more bits than fit in a C double (e.g., on a 64-bit box long may have 63 bits of precision, but a C double probably has only 53), and then we can falsely claim equality when low-order integer bits are lost by coercion to double. So this part is painful too.

[RMPR]

Can you please squash your commits into one and I'll happily merge.

[ra314]

Done. That was quite an interesting read, thanks for the information!

[ra314]

Sorry about that, idk how that space slipped by.