<div class="gmail_quote">On 4 April 2012 10:33, Steven D&#39;Aprano <span dir="ltr">&lt;<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
try:<br>
    from os import bestclock as _bestclock<br>
except ImportError:<br>
    _bestclock = time<br></blockquote><div><br></div><div>My problem here is that &quot;best clock&quot; means different things to different people (as the number of emails shows).</div><div><br></div><div>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.</div>
<div><br></div><div>1. The &quot;steadiest&quot; clock on the system. Ideally this would be a steady clock, but may not be.</div><div><br></div><div>2. The &quot;most precise&quot; clock on the system. This would have the finest-grain tick available on the system.</div>
<div><br></div><div>3. The &quot;highest performance&quot; (or maybe &quot;lowest latency&quot;) clock. This would be whichever clock on the system returned its results fastest.</div><div><br></div><div>I&#39;m not sure if there are more that would be needed (&quot;most accurate&quot; comes to mind, but feels like it&#39;s arbitrarily choosing between steadiest and most precise, so I don&#39;t think it&#39;s valid).</div>
<div><br></div><div>By choosing relative terms, it caters to people&#39;s desire to have the &quot;best&quot; clock, but doesn&#39;t set the expectation that the behaviour is guaranteed.</div><div><br></div><div>Tim Delaney</div>
</div>