> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4