[Python-Dev] PEP 418: Add monotonic time, performance counter and process time functions (original) (raw)

Cameron Simpson cs at zip.com.au
Wed Apr 18 01:34:14 CEST 2012

On 18Apr2012 00:18, Chris Angelico <rosuav at gmail.com> wrote: | On Tue, Apr 17, 2012 at 2:48 PM, Cameron Simpson <cs at zip.com.au> wrote: | > On 16Apr2012 01:25, Victor Stinner <victor.stinner at gmail.com> wrote: | > | I suppose that most people don't care that "resolution" and | > | "precision" are different things. | > | > If we're using the same definitions we discussed offline, where | > | >  - resolution is the units the clock call (underneath) works in (for | >    example, nanoseconds) | > | >  - precision is the effective precision of the results, for example | >    milliseconds | > | > I'd say people would care if they knew, and mostly care about | > "precision". || Meaning that resolution is a matter of format and API, not of clock. | If you take a C clock API that returns a value in nanoseconds and | return it as a Python float, you've changed the resolution. I don't | think resolution matters much, beyond that (for example) nanosecond | resolution allows a clock to be subsequently upgraded as far as | nanosecond precision without breaking existing code, even if currently | it's only providing microsecond precision.

Yes; as stated, resolution is largely irrelevant to the user; it really only places an upper bound on the precision. But it is easy to know from the unlying API doco, so it is easy to annotate the clocks with its metadata.

Annoyingly, the more useful precision value is often harder to know.

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

If anyone disagrees with anything I say, I am quite prepared not only to retract it, but also to deny under oath that I ever said it. - Tom Lehrer

More information about the Python-Dev mailing list