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

[Guido van Rossum]

On Thu, Apr 5, 2012 at 9:48 AM, PJ Eby <pje at telecommunity.com> wrote:
>
>
> On Thu, Apr 5, 2012 at 6:34 AM, Victor Stinner <victor.stinner at gmail.com>
> wrote:
>>
>> 2012/4/5 PJ Eby <pje at telecommunity.com>:
>> >> More details why it's hard to define such function and why I dropped
>> >> it from the PEP.
>> >>
>> >> If someone wants to propose again such function ("monotonic or
>> >> fallback to system" clock), two issues should be solved:
>> >>
>> >>  - name of the function
>> >>  - description of the function
>> >
>> > Maybe I missed it, but did anyone ever give a reason why the fallback
>> > couldn't be to Steven D'Aprano's monotonic wrapper algorithm over the
>> > system
>> > clock?  (Given a suitable minimum delta.)  That function appeared to me
>> > to
>> > provide a sufficiently monotonic clock for timeout purposes, if nothing
>> > else.
>>
>>
>> Did you read the following section of the PEP?
>>
>> http://www.python.org/dev/peps/pep-0418/#working-around-operating-system-bugs
>>
>> Did I miss something? If yes, could you write a patch for the PEP please?
>
>
> What's missing is that if you're using a monotonic clock for timeouts, then
> a monotonically-adjusted system clock can do that, subject to the polling
> frequency -- it does not break just because the system clock is set
> backwards; it simply loses time proportional to the frequency with which it
> is polled.

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. E.g. imagine hitting a website that usually takes 2 seconds
to respond, and setting a timeout to e.g. 4 seconds to bail. If the
timeout somehow gets reduced to 1 second it will appear as if the
website died, whereas if the timeout was increased to 1 hour, nothing
bad would happen unless the website *actually* started having truly
bad response times.

> For timeout purposes in a single process, such a clock is useful.  It just
> isn't suitable for benchmarks, or for interprocess coordination.

I think it would be better if the proposed algorithm (or whatever
algorithm to "fix" timeouts) was implemented by the
application/library code using the timeout (or provided as a separate
library function), rather than by the clock, since the clock can't
know what fallback behavior the app/lib needs.

-- 
--Guido van Rossum (python.org/~guido)