[Python-Dev] PEP 418 is too divisive and confusing and should be postponed (original) (raw)

Cameron Simpson cs at zip.com.au
Thu Apr 5 05:41:02 CEST 2012

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.

More information about the Python-Dev mailing list