On Fri, Mar 23, 2012 at 4:25 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > Hi, > > time.steady(strict=True) looks to be confusing for most people, some > of them don't understand the purpose of the flag and others don't like > a flag changing the behaviour of the function. > > I propose to replace time.steady(strict=True) by time.monotonic(). > That would avoid the need of an ugly NotImplementedError: if the OS > has no monotonic clock, time.monotonic() will just not exist. > > So we will have: > > - time.time(): realtime, can be adjusted by the system administrator > (manually) or automatically by NTP > - time.clock(): monotonic clock on Windows, CPU time on UNIX > - time.monotonic(): monotonic clock, its speed may or may not be > adjusted by NTP but it only goes forward, may raise an OSError > - time.steady(): monotonic clock or the realtime clock, depending on > what is available on the platform (use monotonic in priority). may be > adjusted by NTP or the system administrator, may go backward.
Please don't use the word "steady" for something different from what C++ means by it. C++'s term means "may not be adjusted at all, even by NTP; proceeds at as close to the rate of real time as the system can manage" (paraphrased). If the consensus in the Python community is that a C++-style "steady" clock is unnecessary, then feel free not to define it. If the consensus is that "monotonic" already means everything C++ means by "steady", that's fine with me too. I mentioned it because I thought it might be worth looking at what other languages were doing in this space, not because I thought it was a nice word that you should attach your own definitions to. Jeffrey _______________________________________________ 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