[Python-Dev] PEP 418 is too divisive and confusing and should be postponed
Guido van Rossum
guido at python.org
Thu Apr 5 18:56:19 CEST 2012
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>
>> 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?
>> 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)
More information about the Python-Dev