On Sat, Mar 24, 2012 at 00:36, Victor Stinner <victor.stin...@gmail.com> wrote: >> This seems like it should have been a PEP, or maybe should become a PEP. > > I replaced time.wallclock() by time.steady(strict=False) and > time.monotonic() by time.steady(strict=True). This change solved the > naming issue of time.wallclock(), but it was a bad idea to merge > monotonic() feature into time.steady(). It looks like everybody > agrees, am I wrong?
Yes. As mentioned time.steady(i_mean_it=True) or time.steady(no_not_really=True) doesn't make any sense. Merging the methods may very well make sense, but it should then return a best case and have no flags. I think, as it has been hard to reach an agreement on this that the proposal to only make "stupid" functions that expose the system API's are the correct thing to do at the moment. > - time.time(): realtime, can be adjusted by the system administrator > (manually) or automatically by NTP Sure. > - time.clock(): monotonic clock on Windows, CPU time on UNIX This is for historical reasons, right, because this is what it is now? Would there be a problem in making time.clock() monotonic on Unix as well, if it exists? > - time.monotonic(): monotonic clock, its speed may or may not be > adjusted by NTP but it only goes forward, may raise an OSError > if the OS > has no monotonic clock, time.monotonic() will just not exist. Works for me, > - 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. So it's time.may_or_may_not_be_steady() I don't mind the function, but the name should not be steady(). It's implementation is also so trivial that those who want a monotonic if it exists, but a normal clock otherwise, can simply just do > try: > return time.monotonic() > except (NotImplementError, OSError): > return time.time() themselves. //Lennart _______________________________________________ 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