<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 22, 2015 at 4:15 PM Paul Sokolovsky <<a href="mailto:pmiscml@gmail.com">pmiscml@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Hello from MicroPython, a lean Python implementation<br>
scaling down to run even on microcontrollers<br>
(<a href="https://github.com/micropython/micropython" rel="noreferrer" target="_blank">https://github.com/micropython/micropython</a>).<br>
<br>
Our target hardware base oftentimes lacks floating point support, and<br>
using software emulation is expensive. So, we would like to have<br>
versions of some timing functions, taking/returning millisecond and/or<br>
microsecond values as integers.<br>
<br>
The most functionality we're interested in:<br>
<br>
1. Delays<br>
2. Relative time (from an arbitrary starting point, expected to be<br>
wrapped)<br>
3. Calculating time differences, with immunity to wrap-around.<br>
<br>
The first presented assumption is to use "time.sleep()" for delays,<br>
"time.monotonic()" for relative time as the base. Would somebody gave<br>
alternative/better suggestions?<br>
<br>
Second question is how to modify their names for<br>
millisecond/microsecond versions. For sleep(), "msleep" and "usleep"<br>
would be concise possibilities, but that doesn't map well to<br>
monotonic(), leading to "mmonotonic". So, better idea is to use "_ms"<br>
and "_us" suffixes:<br>
<br>
sleep_ms()<br>
sleep_us()<br>
monotonic_ms()<br>
monotonic_us()<br></blockquote><div><br></div><div>If you're going to add new function names, going with the _unit suffix seems best.</div><div><br></div><div>Another option to consider: keyword only arguments.</div><div><br></div><div>time.sleep(ms=31416)</div><div>time.sleep(us=31415927)</div><div>time.sleep(ns=31415296536)</div><div># We could use the long form names milliseconds, microseconds and nanoseconds but i worry with those that people would inevitably confuse ms with microseconds as times and APIs usually given the standard abbreviations rather than spelled out.</div><div><br></div><div>time.monotonic(return_int_ns=True) ?</div><div># This seems ugly. time.monotonic_ns() seems better.</div><div><br></div><div>These should be acceptable to add to Python 3.6 for consistency.</div><div><br></div><div>I do not think we should have functions for each ms/us/ns unit if adding functions. Just choose the most useful high precision unit and let people do the math as needed for the others.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Point 3 above isn't currently addressed by time module at all.<br>
<a href="https://www.python.org/dev/peps/pep-0418/" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0418/</a> mentions some internal<br>
workaround for overflows/wrap-arounds on some systems. Due to<br>
lean-ness of our hardware base, we'd like to make this matter explicit<br>
to the applications and avoid internal workarounds. Proposed solution<br>
is to have time.elapsed(time1, time2) function, which can take values<br>
as returned by monotonic_ms(), monotonic_us(). Assuming that results of<br>
both functions are encoded and wrap consistently (this is reasonable<br>
assumption), there's no need for 2 separate elapsed_ms(), elapsed_us()<br>
function.<br></blockquote><div><br></div><div>Reading the PEP my takeaway is that wrap-around of underlying deficient system APIs should be handled by the Python VM for the user. It sounds like we should explicitly spell this out though.</div><div><br></div><div>I don't think time.elapsed() could ever provide any utility in either case, just use subtraction. time.elapsed() wouldn't know when and where the time values came from and magically be able to apply wrap around or not to them.</div><div><br></div><div>-gps</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, the above are rough ideas we (well, I) have. We'd like to get wider<br>
Python community feedback on them, see if there're better/alternative<br>
ideas, how Pythonic it is, etc. To clarify, this should not be construed<br>
as proposal to add the above functions to CPython.<br>
<br>
<br>
--<br>
Best regards,<br>
Paul mailto:<a href="mailto:pmiscml@gmail.com" target="_blank">pmiscml@gmail.com</a><br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div></div>