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 rhettinger
Recipients dmoore, ezio.melotti, georg.brandl, giampaolo.rodola, gvanrossum, rhettinger, steven.daprano, tim.peters
Date 2014-06-14.02:30:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1402713041.57.0.188958079902.issue19495@psf.upfronthosting.co.za>
In-reply-to
Content
This idea is a bit at odds with the design of the rest of the time-it module which seeks to:

* run small snippets of code in volume rather than "trying to find bottlenecks in large programs without interfering with their operation".  The latter task is more suited to the profiling modules.

* run code inside a function (local variables have difference performance characteristics than global lookups).

* take care of running the loop for you (including repeated measurements and setup code) instead of your writing your own loop as done the proposed code fragment).

* return the output rather than print it

* minimize the overhead of the timing suite itself (using itertools.repeat  to control the number of loops, etc) unlike the class based version which introduces its own overhead.

It might still be worth having a time elapsed decorator, but I wanted to note that this isn't in the spirit of the rest of the module.
History
Date User Action Args
2014-06-14 02:30:41rhettingersetrecipients: + rhettinger, gvanrossum, tim.peters, georg.brandl, giampaolo.rodola, ezio.melotti, steven.daprano, dmoore
2014-06-14 02:30:41rhettingersetmessageid: <1402713041.57.0.188958079902.issue19495@psf.upfronthosting.co.za>
2014-06-14 02:30:41rhettingerlinkissue19495 messages
2014-06-14 02:30:40rhettingercreate