[Python-Dev] Drop the new time.wallclock() function? (original) (raw)
Victor Stinner victor.stinner at gmail.com
Tue Mar 27 01:07:39 CEST 2012
- Previous message: [Python-Dev] Drop the new time.wallclock() function?
- Next message: [Python-Dev] Drop the new time.wallclock() function?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
Python 3.2 doesn't provide a monotonic clock, so most program uses time.time() even if a monotonic clock would be better in some functions. For these programs, you can replace time.time() by time.steady() where you need to compute a time delta (e.g. compute a timeout) to avoid issues with the system clock update. The idea is to improve the program without refusing to start if no monotonic clock is available.
Victor
- Previous message: [Python-Dev] Drop the new time.wallclock() function?
- Next message: [Python-Dev] Drop the new time.wallclock() function?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]