[Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

[Cameron Simpson]

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.py

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 at 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 at 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 at 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 at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Life is uncertain.  Eat dessert first.  - Jim Blandy