On 27/03/2012 18:45, Victor Stinner wrote: > [snip...] >> 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). It is this always-having-to-manually-fallback-depending-on-os that I was hoping your new functionality would avoid. Is time.try_monotonic() suitable for this usecase? Michael > >> 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 at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
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