[Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[PJ Eby]

On Thu, Apr 5, 2012 at 12:56 PM, Guido van Rossum <guido at python.org> wrote:

> Depending on the polling frequency sounds like a bad idea, since you
> can't know that you're the only user of the clock. Also depending on
> the use case, too short a timeout may be worse than too long a
> timeout.


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.

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.

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.

Or more to the point, "If the implementation is hard to explain, it's a bad
idea."  ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120405/57d8af2a/attachment.html>