[Python-ideas] millisecond and microsecond times without floats

[Paul Sokolovsky]

Hello from MicroPython, a lean Python implementation
scaling down to run even on microcontrollers 
(https://github.com/micropython/micropython).

Our target hardware base oftentimes lacks floating point support, and
using software emulation is expensive. So, we would like to have
versions of some timing functions, taking/returning millisecond and/or
microsecond values as integers.

The most functionality we're interested in:

1. Delays
2. Relative time (from an arbitrary starting point, expected to be
   wrapped)
3. Calculating time differences, with immunity to wrap-around.

The first presented assumption is to use "time.sleep()" for delays,
"time.monotonic()" for relative time as the base. Would somebody gave
alternative/better suggestions?

Second question is how to modify their names for
millisecond/microsecond versions. For sleep(), "msleep" and "usleep"
would be concise possibilities, but that doesn't map well to
monotonic(), leading to "mmonotonic". So, better idea is to use "_ms"
and "_us" suffixes:

sleep_ms()
sleep_us()
monotonic_ms()
monotonic_us()

Point 3 above isn't currently addressed by time module at all.
https://www.python.org/dev/peps/pep-0418/ mentions some internal
workaround for overflows/wrap-arounds on some systems. Due to
lean-ness of our hardware base, we'd like to make this matter explicit
to the applications and avoid internal workarounds. Proposed solution
is to have time.elapsed(time1, time2) function, which can take values
as returned by monotonic_ms(), monotonic_us(). Assuming that results of
both functions are encoded and wrap consistently (this is reasonable
assumption), there's no need for 2 separate elapsed_ms(), elapsed_us()
function.


So, the above are rough ideas we (well, I) have. We'd like to get wider
Python community feedback on them, see if there're better/alternative
ideas, how Pythonic it is, etc. To clarify, this should not be construed
as proposal to add the above functions to CPython.


-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com