> What is the utility of "strict=True"? If I wanted that mode of > operation, then why would I not just try to use "time.monotonic()" > directly?
I mentioned the strict=True API in the PEP just to list all propositions, but the PEP only proposes time.monotonic() and time.try_monotonic(), no the flags API. > At worst, it generates an "AttributeError" (although that is not clear from > your PEP). I tried to mention when a function is always available or not always available. Is it better in the last version of the PEP? > system_clock = wall clock time > monotonic_clock = always goes forward but can be adjusted > steady_clock = always goes forward and cannot be adjusted > high_resolution_clock = steady_clock || system_clock I tried to follow these names in the PEP. I don't propose steady_clock because I don't see exactly which clocks would be used to implement it, nor if we need to provide monotonic *and* steady clocks. What do you think? > Straying from that is only going to create confusion. Besides that, the > one use case for "time.steady()" that you give (benchmarking) is better > served by a clock that follows the C++0x definition. I added a time.hires() clock to the PEP for the benchmarking/profiling use case. This function is not always available and so a program has to fallback manually to another clock. I don't think that it is an issue: Python programs already have to choose between time.clock() and time.time() depending on the OS (e.g. timeit module and pybench program). > As well, certain > kinds of scheduling/timeouts would be better implemented with the C++0x > definition for "steady" rather than the "monotonic" one and vice-versa. Sorry, I don't understand. Which kind of scheduling/timeouts? The PEP is still a draft (work-in-progress). 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
