Hello, On Tue, 23 Jun 2015 00:03:14 +0000 "Gregory P. Smith" <greg@krypto.org> wrote: []
sleep_ms() sleep_us() monotonic_ms() monotonic_us()
If you're going to add new function names, going with the _unit suffix seems best.
Another option to consider: keyword only arguments.
time.sleep(ms=31416) time.sleep(us=31415927) time.sleep(ns=31415296536)
That doesn't immediately map to usage for monotonic(), as you mention below. Another issue is that keywords arguments on average (and for MicroPython all the time) are less efficient than positional. Put it other way, t = monotonic_ns() t = monotonic_ns() - t is going to give lower number than t = monotonic(ns=True) t = monotonic(ns=True) - t , and the closer it to 0, the better.
# 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.
Another issue is that full spellings are rather long. Logistically, while function names can be expected to have autocompletion support, keyword arguments not necessarily.
time.monotonic(return_int_ns=True) ? # This seems ugly. time.monotonic_ns() seems better.
These should be acceptable to add to Python 3.6 for consistency.
Well, as I mentioned, I'm personally not looking for this to be implemented in CPython right away. Ideally, this should be tested by >1 independent "embedded" Python implementation first, and only then, based on the actual experience, submitted as a PEP. That's rather better than "desktop" CPython, which doesn't care about all the subtle "embedded" aspects "forced" a way to implement it.
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.
Well, that's one of examples of that "desktop" thinking ;-). Consider for example that 2^32 microseconds is just over an hour, so expressing everything in microseconds would require arbitrary-precision integers, which may be just the same kind of burden for an embedded system as floats.
Point 3 above isn't currently addressed by time module at all. https://www.python.org/dev/peps/pep-0418/ mentions some internal
[]
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.
This is another point which is overlooked by "desktop" programmers - time counters can, will, and do wrap around. Big OSes try hard to to hide this fact, and indeed succeed well enough, so in cases when they do fail, it has shattering effect (at least PR-wise) - Y2K, Y2K38 problems. For an embedded programmer wrapping counters is objective reality, and we wouldn't like to hide that fact in MicroPython (of course, only for these, newly introduced real-time precision time functions).
I don't think time.elapsed() could ever provide any utility in either case, just use subtraction.
Can't work. Previous value of monotonic_us() is 65530, next value is 10, what does it tell you?
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.
Well, as I mentioned, it's an API contract that elapsed() takes values of monotonic_ms(), monotonic_us(), etc. functions, and knows law how their values change (likely, apply unsigned power-of-2 modular arithmetics). There's additional restriction that this change law for all of monotonic_ms(), monotonic_us() is the same, but I personally find this an acceptable restriction to not bloat API even further. (But it is a restriction, for example, if nano/microsecond time source is 24-bit counter, than millisecond time is limited to 24 bits too).
-gps
-- Best regards, Paul mailto:pmiscml@gmail.com