Connelly Barnes wrote: > Hi, > > Perhaps I am the only one bothered by the timeit > module, but it seems poorly designed to me. > > First of all, it should use a geometric series with a > timeout value to detect how many iterations it should > perform. Currently, the user is required to manually > specify the number of iterations (the default is 1 The provision of a default value generally seems to chop the legs from your argument that the number of iterations is required. > million). If the user optimizes his or her code, then > the number of iterations must be changed. If the user > moves to a slower or faster computer, then the number > of iterations must be changed again. This is > annoying. > What? The purpose of timeit is to give an approximation to the length of time to run a specific piece ofcode. Why must the number of iterations be changed when moving to a slower or faster computer? > Secondly, there should be a way to time a callable > directly. That is, without finding the string name of > the callable and using a string "import X" statement. > These contortions violate rules #1 and #3 of the Zen > of Python. > Presumably for benchmarking purposes the function call overhead would be present for all compaered techniques. Do you mean rules #0 and #2? > [...] regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4