[Python-Dev] Drop the new time.wallclock() function?

Glyph glyph at twistedmatrix.com
Tue Mar 27 00:47:05 CEST 2012


On Mar 26, 2012, at 6:31 PM, Zooko Wilcox-O'Hearn wrote:

> On Fri, Mar 23, 2012 at 11:27 AM, Victor Stinner
> <victor.stinner at gmail.com> wrote:
>> 
>> time.steady(strict=False) is what you need to implement timeout.
> 
> No, that doesn't fit my requirements, which are about event
> scheduling, profiling, and timeouts. See below for more about my
> requirements.
> 
> I didn't say this explicitly enough in my previous post:
> 
> Some use cases (timeouts, event scheduling, profiling, sensing)
> require a steady clock. Others (calendaring, communicating times to
> users, generating times for comparison to remote hosts) require a wall
> clock.
> 
> Now here's the kicker: each use case incur significant risks if it
> uses the wrong kind of clock.
> 
> If you're implementing event scheduling or sensing and control, and
> you accidentally get a wall clock when you thought you had a steady
> clock, then your program may go seriously wrong -- events may fire in
> the wrong order, measurements of your sensors may be wildly incorrect.
> This can lead to serious accidents. On the other hand, if you're
> implementing calendaring or display of "real local time of day" to a
> user, and you are using a steady clock for some reason, then you risk
> displaying incorrect results to the user.
> 
> So using one kind of clock and then "falling back" to the other kind
> is a choice that should be rare, explicit, and discouraged. The
> provision of such a function in the standard library is an attractive
> nuisance -- a thing that people naturally think that they want when
> they haven't though about it very carefully, but that is actually
> dangerous.
> 
> If someone has a use case which fits the "steady or else fall back to
> wall clock" pattern, I would like to learn about it.

I feel that this should be emphasized.  Zooko knows what he's talking about here.  Listen to him :).  (Antoine has the right idea.  I think it's well past time for a PEP on this feature.)

-glyph



More information about the Python-Dev mailing list