> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
