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 steven.daprano
Recipients amaury.forgeotdarc, asvetlov, eric.araujo, ncoghlan, pitrou, rbcollins, rhettinger, scott_daniels, steven.daprano, tshepang, vstinner
Date 2016-05-11.15:28:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
This issue seems to have lost momentum, I'd like to revive it by proposing a slightly different interface for the autorange function.

Attached is a proof-of-concept patch. I've moved the code which determines the number of loops out of the main function into a new Timer method, ``autorange``. The main difference between my approach and Scott's is that my autorange method doesn't do any printing directly, it takes an optional callback function. This lets the caller take responsibility for all output.

If this approach is acceptable, I hope to:

- (in 3.6) add tests and docs for the new method;

- (in 3.6 if time permits, otherwise 3.7) modify the timeit and repeat methods and functions so that they can optionally call autorange(), e.g. if the caller passes 0 as the number.

I'm not sure that there's a good reason to add a top-level autorange() function to match the timeit() and repeat() functions. Especially not once they gain the ability to autorange themselves.

I think my approach will be compatible with cleaning up and refactoring the main() function. At the moment, main() is a mess IMO, it handles argument processing, autoranging, units of time, and unreliable timing detection all from one function.
Date User Action Args
2016-05-11 15:28:05steven.dapranosetrecipients: + steven.daprano, rhettinger, scott_daniels, amaury.forgeotdarc, ncoghlan, pitrou, vstinner, rbcollins, eric.araujo, asvetlov, tshepang
2016-05-11 15:28:05steven.dapranosetmessageid: <>
2016-05-11 15:28:05steven.dapranolinkissue6422 messages
2016-05-11 15:28:05steven.dapranocreate