+1 for steady(). On Wed, Mar 14, 2012 at 10:15 AM, Matt Joiner <anacro...@gmail.com> wrote: > FWIW the name is quite important, because these kind of timings are > quite important so I think it's worth the effort. > >> - By default, it should fall back to time.time if a better source is >> not available, but there should be a flag that can disable this >> fallback for users who really *need* a monotonic/steady time source. > > Agreed. As Guido mentioned, some platforms might not be able to access > to hardware times, so falling back should be the default, lest unaware > users trigger unexpected errors. > >> - Proposed names for the function: >> * monotonic > > Doesn't indicate that the timing is also prevented from leaping forward. > >> * steady_clock > > I think the use of clock might infer CPU time on doc-skimming user. > "clock" is overloaded here. > >> For the flag name, I'm -1 on "monotonic" -- it sounds like a flag to >> decide whether to use a monotonic time source always or never, while >> it actually decides between "always" and "sometimes". I think "strict" >> is nicer than "fallback", but I'm fine with either one. > > I agree, "strict" fits in with existing APIs. > > I think time.hardware(), and time.steady() are still okay here.
-- --Guido van Rossum (python.org/~guido) _______________________________________________ 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
