[Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Cameron Simpson]

On 04Apr2012 22:23, PJ Eby <pje at telecommunity.com> wrote:
| On Apr 4, 2012 7:28 PM, "Victor Stinner" <victor.stinner at gmail.com> wrote:
| > More details why it's hard to define such function and why I dropped
| > it from the PEP.
| >
| > If someone wants to propose again such function ("monotonic or
| > fallback to system" clock), two issues should be solved:
| >
| >  - name of the function
| >  - description of the function
| 
| Maybe I missed it, but did anyone ever give a reason why the fallback
| couldn't be to Steven D'Aprano's monotonic wrapper algorithm over the
| system clock?  (Given a suitable minimum delta.)  That function appeared to
| me to provide a sufficiently monotonic clock for timeout purposes, if
| nothing else.

It was pointed out (by Nick Coglan I think?) that if the system clock
stepped backwards then a timeout would be extended by at least that
long. For example, code that waited (by polling the synthetic clock)
for 1s could easily wait an hour if the system clock stepped back that
far. Probaby undesirable.

I think synthetic clocks are an extra task; they will all have side
effects of one kind of another.

A system monotonic clock, by contrast, may have access to some clock
hardware that doesn't step when the "main" system clock gets adjusted,
and can stay monotonic. A synthetic clock without such access can't
behave as nicely.

If synthetic clocks get handed out as fallback there should be some way
for the user to know, or a big glaring negative guarrentee in the docs
and on platforms without a system monotonic clock you might get a clock
with weird (but monotonic!) behaviours if you use the fallback.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Tachyon: A gluon that's not completely dry.