[Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()? (original) (raw)

Cameron Simpson cs at zip.com.au
Fri Mar 30 23:43:19 CEST 2012


On 30Mar2012 13:52, Guido van Rossum <guido at python.org> wrote: | (In fact, this even argues against having both the timer with fallback | and the timer without fallback. So maybe we should just have a single | timer function, with fallback, and a separate mechanism to inquire | its properties.)

Well, you should be able to know what kind of clock you're getting. But what do to if you don't get a satisfactory one? There's then no way for ask for an alternative; you don't get to control the fallback method, for example.

I've come to the opinion that the chosen approach is wrong, and suggest a better one.

There seem to be a few competing features for clocks that people want:

and only a few, fortunately.

I think you're doing this wrong at the API level. People currently are expecting to call (for example) time.monotonic() (or whatever) and get back "now", a hopefully high resolution float.

Given the subtlety sought for various purposes, people should be calling:

T = time.getclock(flags)

and then later calling:

T.now()

to get their float.

That way people can:

Then users can request a less featured clock on failure, depending on what aspects of the clock are most desirable to their use case. Or of course fail if fallback is not satisfactory.

Of course you can provide some convenient-with-fallback function that will let people do this in one hit without the need for "T", but it should not be the base facility offered. The base should let people request their feature set and inspect what is supplied.

Cheers,

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

Time is nature's way of keeping everything from happening at once.



More information about the Python-Dev mailing list