This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients belopolsky, benhoyt, benjamin.peterson, ethan.furman, fdrake, lemburg, mrabarnett, serhiy.storchaka, vstinner
Date 2017-10-18.09:15:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1508318142.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
In-reply-to
Content
"Initially the time module was a thin wrapper around C and OS time-related functions. It may be confusing that the behavior of time.clock() differs from the behavior of C's clock()."

Well, there is the theory, and there is the practice. Someone decided to implement time.clock() with QueryPerformanceCounter() on Windows, and so time.clock() is no more a thin wrapper to the C clock() function since at least Python 2.7 (I didn't check earlier versions).

Portability on clocks is even more than complex than in the os module, especially when you want the same behaviour on Windows and Unix. The PEP 418 added new clocks with a better defined behaviour to "fix" this issue.


"The documentation for clock() on MSDN suggests to use GetProcessTimes() for the behavior conforming the C standard."

time.process_time() is implemented with GetProcessTimes(). That's why time.clock() suggests to either replace it with time.perf_counter() or time.process_time().
History
Date User Action Args
2017-10-18 09:15:42vstinnersetrecipients: + vstinner, lemburg, fdrake, belopolsky, benjamin.peterson, mrabarnett, benhoyt, ethan.furman, serhiy.storchaka
2017-10-18 09:15:42vstinnersetmessageid: <1508318142.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
2017-10-18 09:15:42vstinnerlinkissue31803 messages
2017-10-18 09:15:42vstinnercreate