[Python-Dev] PEP 418 is too divisive and confusing and should be postponed

Victor Stinner victor.stinner at gmail.com
Sat Apr 7 01:01:45 CEST 2012


> 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


More information about the Python-Dev mailing list