On 7 April 2012 09:12, Stephen J. Turnbull <step...@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. _______________________________________________ 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
