On 7 April 2012 09:12, Stephen J. Turnbull <stephen at xemacs.org> wrote: > > I don't think that's a reason that should be considered. There just > doesn't seem to be a single best clock, nor do clocks of similar > character seem to be easy to find across platforms. So the reasons > I'd like to see are of the form "we should provide CLOCK_MONOTONIC on > Linux as one of our small selection of recommended clocks *because* > the frequency adjustment makes it *most* useful in use-cases A and B, > and it's a *reasonable* choice in use-case C *but* we need to document > that it's a terrible choice for use-case D." >From the PEP: """ Use cases: Display the current time to a human (e.g. display a calendar or draw a wall clock): use system clock, i.e. time.time() or datetime.datetime.now(). Event scheduler, timeout: time.monotonic(). Benchmark, profiling: time.clock() on Windows, time.monotonic(), or fallback to time.time() Functions To fulfill the use cases, the functions' properties are: time.time(): system clock, "wall clock". time.monotonic(): monotonic clock time.get_clock_info(name): get information on the specified time function """ That broadly covers it, I'd say. There are 2 main exceptions I see: (1) your suggestion of "explain why clock X is a terrible choice for use case Y" isn't there, although I'm not sure how important that is, and (2) there's no really good cross-platform option given for benchmarking/profiling (time.clock() is fine on Windows, but it gives CPU time on Unix - is that acceptable?) Also, Victor - you missed time.clock() from "Functions". Was that deliberate because it's sometimes CPU time? Maybe it should be added for clarity? Paul.
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