[Python-Dev] PEP 418 is too divisive and confusing and should be postponed
timothy.c.delaney at gmail.com
Sat Apr 7 00:17:15 CEST 2012
On 4 April 2012 10:33, Steven D'Aprano <steve at pearwood.info> wrote:
> from os import bestclock as _bestclock
> except ImportError:
> _bestclock = time
My problem here is that "best clock" means different things to different
people (as the number of emails shows).
I think exposing specific clocks is also useful (sometimes people may need
a steady clock, and early failure is better than clock skew). However, I
propose a loosely classified set of clocks built on top of the specific
clocks, all of which can fall back to the lowest precision/non-monotonic
clock if needed.
1. The "steadiest" clock on the system. Ideally this would be a steady
clock, but may not be.
2. The "most precise" clock on the system. This would have the finest-grain
tick available on the system.
3. The "highest performance" (or maybe "lowest latency") clock. This would
be whichever clock on the system returned its results fastest.
I'm not sure if there are more that would be needed ("most accurate" comes
to mind, but feels like it's arbitrarily choosing between steadiest and
most precise, so I don't think it's valid).
By choosing relative terms, it caters to people's desire to have the "best"
clock, but doesn't set the expectation that the behaviour is guaranteed.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev