> 1. The "steadiest" clock on the system. Ideally this would be a steady > clock, but may not be.
time.monotonic() as proposed in the PEP 418 *is* the steadiest available clock, but we cannot say that it is steady :-) > 2. The "most precise" clock on the system. This would have the finest-grain > tick available on the system. It's discussed in the "Deferred API: time.perf_counter()" section. It would be nice to provide such clock, but I don't feel able right now to propose ab API for such requirement. It's unclear to me if it must be monotonic, steady, count elapsed time during a sleep or not, etc. It is already very hard to propose one single time function (time.monotonic), so I chose to simplify the PEP and not propose two functions but only one :-) > 3. The "highest performance" (or maybe "lowest latency") clock. This would > be whichever clock on the system returned its results fastest. Linux provides CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE clocks, reading the ACPI Power Management clock is known to be slow. But should the clock be monotonic or not? Return seconds or CPU ticks? If the clock is not well defined, it's useless or at least, not portable. Exposing CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE constants should be enough. Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
