[Python-Dev] PEP 418 is too divisive and confusing and should be postponed (original) (raw)

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