FWIW the name is quite important, because these kind of timings are quite important so I think it's worth the effort. > - By default, it should fall back to time.time if a better source is > not available, but there should be a flag that can disable this > fallback for users who really *need* a monotonic/steady time source. Agreed. As Guido mentioned, some platforms might not be able to access to hardware times, so falling back should be the default, lest unaware users trigger unexpected errors. > - Proposed names for the function: > * monotonic Doesn't indicate that the timing is also prevented from leaping forward. > * steady_clock I think the use of clock might infer CPU time on doc-skimming user. "clock" is overloaded here. > For the flag name, I'm -1 on "monotonic" -- it sounds like a flag to > decide whether to use a monotonic time source always or never, while > it actually decides between "always" and "sometimes". I think "strict" > is nicer than "fallback", but I'm fine with either one. I agree, "strict" fits in with existing APIs. I think time.hardware(), and time.steady() are still okay here.
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