The existing tests

I've manually verified the new values:

>>>time.get_clock_info("process_time")namespace(implementation='GetProcessTimes()',monotonic=True,adjustable=False,resolution=0.015625)>>>time.get_clock_info("thread_time")namespace(implementation='GetThreadTimes()',monotonic=True,adjustable=False,resolution=0.015625)

cc@vstinner since#82040 (comment)

Patches are welcome to enhance time.get_clock_info() :-)

This isn't the way, I'm afraid. The specified resolution is all we know, and undocumented behaviours like the resolution a system is actually going to write into the data structures isn't something we should be hard coding and relying on.

These functions should really only be used for reporting, not for decision making. If tests want to use them for decision making, then they also need a control to verify that they're going to work as intended (e.g. run a known amount of work and make sure that it registers in these functions).

At worst, we should try and read the current interval, rather than hard-coding the worst case scenario. But even that's risky, as it can change while the system is running (not a great idea, because programsdo rely on it, and they can get into trouble as it changes, but we shouldn't be encouraging people to write code like tht).

Ah, ok, I see. Even the PEP (https://peps.python.org/pep-0418/#process-time) lists

These functions should really only be used for reporting, not for decision making

Seems to happen even in the stdlib

Maybe just adocumentation issue?

Converting to draft tagging asDO-NOT-MERGE ...

The PEP isn't the documentation of the OS. If you can find a reference on learn.microsoft.com that states the resolution of that specific function, then we can lock it in. But you won't, because the resolution of the actual timer is deliberately left unspecified. (You'll find examples showing that it's typically around 15ms and adjustable down for some benefit in some situations, but no guarantees.)

A lot of code in the stdlib, and especially its test suite, is "best effort" to make something work. It's not necessarily a robust example of the best way to implement something. Trust the upstream docs, just like we expect people to trust ours 😉

Oh yes, I frequently read the MSDN :)

With

Maybe just a documentation issue?

I meant we could add some hints about that tohttps://docs.python.org/3/library/time.html#time.get_clock_info

resolution: The resolution of the clock in seconds (float)

Specifically something like

These functions should really only be used for reporting, not for decision making

Clarifying documentation is always fine, provided it doesn't specify us into a corner. Something along the lines of "this is a theoretical resolution, and not necessarily the rate at which the values are updated" and "these functions should not be treated as high-precision timers on most operating systems" would be fine.

I suggest to report 15.625 ms, since this is the upper limit.

time.get_clock_info() should report the lower limit. On Linux, it reports 1 nanosecond for most clocks even if it's the actual resolution, just because the C structure has a resolution of 1 nanosecond.

Yes, documentation changes are welcomed to clarify that.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

time.get_clock_info() should report the lower limit.

IIUC,@zooba would oppose (?) because

But you won't, because the resolution of the actual timer is deliberately left unspecified.

So I think we shouldn't change anything but just add some notes to the documentation?

Best to close this PR and keep the the discussion on the issue? And then (maybe) create a documentation PR?

So I think we shouldn't change anything but just add some notes to the documentation?

Correct. Unless the OS provides an API to query the resolution.