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, fdrake, lemburg, serhiy.storchaka, vstinner
Date 2017-10-17.13:39:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1508247554.31.0.213398074469.issue31803@psf.upfronthosting.co.za>
In-reply-to
Content
Serhiy: "I think it is better to not remove time.clock() until EOL of 2.7. And in any case it first should start emitting a deprecation warning for a one or two releases."

I really hate using 2.7 EOL as the final countdown to start changing things. Are we building a new "Python 3" chaos where everything explode at once?

IMHO it's not that hard to write code compatible with Python 2 and Python 3:

try:
   from time import perf_counter # Python 3
except ImportError:
   from time import clock as perf_counter # Python 2

time.clock() is probably not the only code which requires two code paths in any non trivial application which wants to stay compatible with Python 2.

time.clock() is usually used for benchmarking. I hope that all benchmarking code was already patched to use time.perf_counter() when available, to make the code portable and get better resolution on Unix.
History
Date User Action Args
2017-10-17 13:39:14vstinnersetrecipients: + vstinner, lemburg, fdrake, belopolsky, benjamin.peterson, benhoyt, serhiy.storchaka
2017-10-17 13:39:14vstinnersetmessageid: <1508247554.31.0.213398074469.issue31803@psf.upfronthosting.co.za>
2017-10-17 13:39:14vstinnerlinkissue31803 messages
2017-10-17 13:39:14vstinnercreate