[Python-Dev] Drop the new time.wallclock() function? (original) (raw)
Yury Selivanov yselivanov.ml at gmail.com
Fri Mar 23 23:56:08 CET 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 ]
On 2012-03-23, at 1:27 PM, Victor Stinner wrote:
I want time.steady(strict=True), and I'm glad you're providing it and I'm willing to use it this way, although it is slightly annoying because "time.steady(strict=True)" really means "time.steady(ireallymeanit=True)". Else, I would have used "time.time()".
I am aware of a large number of use cases for a steady clock (event scheduling, profiling, timeouts), and a large number of uses cases for a "NTP-respecting wall clock" clock (calendaring, displaying to a user, timestamping). I'm not aware of any use case for "steady if implemented, else wall-clock", and it sounds like a mistake to me. time.steady(strict=False) is what you need to implement timeout. If you use time.steady(strict=True) for timeout, it means that you cannot use select, threads, etc. if your platform doesn't provide monotonic clock, whereas it works "well" (except the issue of adjusted time) with Python < 3.3.
Why can't I use select & threads? You mean that if a platform does not support monotonic clocks it also does not support threads and select sys call?
- Yury
- 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 ]