Victor et al, Just an update note: I've started marking up clocks with attributes; not yet complete and I still need to make a small C extension to present the system clocks to Python space (which means learning to do that, too). But you can glance over the start on it here: https://bitbucket.org/cameron_simpson/css/src/tip/lib/python/cs/clockutils.p... Several feature flags and some properties for qualifying clocks. Still needed stuff includes: C access to clocks, .accuracy being actual clock precision versus the resolution of the units in the underlying OS call, a __repr__ and/or __str__ to decode feature bitmaps into useful strings, .is_*() __getattr__ method to resolve against flags by name or maybe has_flag(str), etc. On 07Apr2012 01:16, Victor Stinner <victor.stinner@gmail.com> wrote: | > | This is the original reason for the original defect (issue 10278) | > | unix' clock() doesn't actually provide a clock in this sense, | > | it provides a resource usage metric. | > | > Yeah:-( Its help says "Return the CPU time or real time since [...]". | > Two very different things, as demonstrated. I suppose neither goes | > backwards, but this seems like a classic example of the "useless | > monotonic clock" against which Greg Ewing railed. | > | > And why? For one thing, because one can't inspect its metadata to find | > out what it does. | | Should I add another key to the result of | time.get_clock_info('clock')? How can we define "clock on Windows" | (almost monotonic and steady clock) vs "clock on UNIX" (CPU time) with | a flag or a value? For clocks I'm going with two feature flags: WALLCLOCK and RUNTIME. The former indicates a clock that tries to stay in synch with real world time, and would still advance when the system is suspended or idle; it would almost certainly need to "step" over a suspend. The latter means system run time; it accrues only while the system is up. Neither is CPU usage (so a time.sleep(10) would add 10 seconds to both). I think resource usage is not a "clock". We could characterise such timers and counters with a lot of the same metrics we like to use with clocks, but I do not think they should be returned by a system purporting to return clocks or clock values. On 07Apr2012 14:22, I wrote: | On 06Apr2012 17:30, Glenn Linderman <v+python@g.nevcal.com> wrote: | | Hopefully, for each system, the characteristics of each clock can be | | discovered, and fully characterized in available metadata for the clock... | | Victor has asked me to do that for my skeleton, based on the tables he | has assembled. I'll see what i can do there... I've started on this, see above. Victor Stinner <victor.stinner@gmail.com> wrote: | | - define flags of all clocks listed in the PEP 418: clocks used in | | the pseudo-code of time.steady and time.perf_counter, and maybe also | | time.time | | I'll make one. It will take a little while. Will post again when ready. So, new code to glance over as evidence of good faith, if not speed:-( Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ Life is uncertain. Eat dessert first. - Jim Blandy