On 03Apr2012 13:26, Victor Stinner <victor.stin...@gmail.com> wrote: | I would to rename time.monotonic() to time.steady() in the PEP 418 for | the following reasons: | | - time.steady() may fallback to the system clock which is not | monotonic, it's strange to have to check for | time.get_clock_info('monotonic')['is_monotonic'] | - time.steady() uses GetTickCount() instead of | QueryPerformanceCounter() whereas both are monotonic, but | QueryPerformanceCounter() is not steady | | Python steady clock will be different than the C++ definition. | | You may argue that time.steady() is not always steady: it may fallback | to the system clock which is adjusted by NTP and can jump | backward/forward with a delta greater than 1 hour.
An HOUR ?!?!? I have to say I'm -100 on any proposal where time.monotonic() returns non-monotonic time and likewise for time.steady() returning unsteady time. | In practice, there | is only one operating system that does not provide a monotonic clock: | GNU/Hurd. I'd have thought practically any early UNIX falls into this category. And any number of other niche things. (Yes I know Python doesn't run on everything anyway.) Are we only considering Linux/Mac/Windows, and only recent versions of those? What's the status of Java and Jython? | I hesitate to add "is_steady" to time.get_clock_info(), but a boolean | is not very useful, it would be better to have a number. | | Arguments for time.monotonic() name: | | - Users are looking for the "monotonic" name | - Most of the time, time.monotonic() is a monotonic clock Again, here, I'm -100 on "most". If I ask for monotonic, it is because I need one. Given me monotonic or give me death! (Well, an exception or at any rate something unusable like None.) [...] | PS: I already changed time.monotonic() to time.steady() in the PEP :-p Sigh. They're different things! For all that "steady" is a slightly vague term, steady and hires and monotonic are independent concepts. Of course a lot of high quality clocks will embody hires and ideally steady or monotonic. This kind of offer-just-one-thing embedded policy is why I feel the API needs more user control and a polciy free interface, with montonic() et al providing handy prepackaged policy for the common uses. If you can provide monotonic (for example, on Linux as you outline), which _not_ offer it? Offering steady() provides no way for the user to ask for higher guarentees. Cheers, -- Cameron Simpson <c...@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ But in our enthusiasm, we could not resist a radical overhaul of the system, in which all of its major weaknesses have been exposed, analyzed, and replaced with new weaknesses. - Bruce Leverett _______________________________________________ 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