[Python-Dev] release candidate rules and timeit API question

Tim Peters tim.one@comcast.net
Mon, 30 Jun 2003 21:29:30 -0400


[Brett]
> ...
> My timeit API question has to do with timeit.default_timer .  The docs
> don't mention it but I think it might be nice to expose it.  The
> specific I would like to have it available for guaranteed use is that
> both 'threading' and Queue have code that sleep on an ever-increasing
> interval.  They both use time.time for their time measurements which
> is fine on UNIX but sucks on Windows when you consider the max time
> both chunks of code wait is .05 secs which is below the accuracy
> threshold for Windows (according to Tim's intro in the Cookbook;
> thank god for books when tech goes kapoot).  I would like to edit the
> code so that it uses what timeit.default_timer is set to.  Anyone
> (especially Guido since he is timeit's original author) have a
> problem with documenting timeit.default_timer?

The sleep loop in threading.py is fine as-is:  time.time != time.sleep, and
there's no problem on Windows sleeping for small bits of time.  The coarse
granularity of time.time() on Windows only comes into play if the total
timeout specified is < about 0.055 seconds, but that's a very small total
timeout value (more typical is a total timeout of a full second or more).
Queue uses the same polling loop code, and it's also fine there.  It's not
so fine that this delicate code is duplicated, so I'd rather see an internal
refactoring to use a common backoff-polling class.