On 4 April 2012 10:33, Steven D'Aprano <st...@pearwood.info> wrote:
> try:
> 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.
Tim Delaney
_______________________________________________
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
