<div class="gmail_quote">On Thu, Apr 5, 2012 at 12:56 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div class="h5">Depending on the polling frequency sounds like a bad idea, since you</div></div>
can't know that you're the only user of the clock. Also depending on<br>
the use case, too short a timeout may be worse than too long a<br>
timeout. </blockquote><div><br></div><div>Given a small enough delta, the timeout won't be too short. (Steven's original code sample I believed used either 0 or 1 as a delta, but it could be as small a fraction as will add correctly in the datatype used.) And the worst case polling frequency is the length of the timeout, meaning you can't end up with more than double your intended timeout.</div>
<div><br></div><div>In the opposite scenario, where the time is polled in a tight loop, then as long as Python doesn't sample the raw clock so often that the summed fractional deltas exceeds the real clock speed, the timeout won't be shortened by any appreciable amount. In fact, this can be guaranteed by measuring time as a (raw, increment) tuple, where the increment can be an arbitrarily-large integer. Each new time value is greater than the one before, yet the real component remains untouched. With this approach, the timeout can only be delayed for however long the system clock *stops*, and the timeout can only be shortened by the system clock skipping ahead.</div>
<div><br></div><div>Okay, having thought that out, I now agree that there are too many fine points to make this cover enough of the use cases without needing parameters.</div><div><br></div><div>Or more to the point, "If the implementation is hard to explain, it's a bad idea." ;-)</div>
<div> </div></div>