Well, maybe all we need is the timeit module, then? I didn't realize that we have default_timer there. Otherwise, I'm not sure about "timer". To me that word implies some sort of context to be timed, or action to be taken, but I'm +0 on it. K -----Original Message----- From: python-ideas-bounces+kristjan=ccpgames.com@python.org [mailto:python-ideas-bounces+kristjan=ccpgames.com@python.org] On Behalf Of Steven D'Aprano Sent: Tuesday, November 02, 2010 9:51 To: python-ideas@python.org Subject: Re: [Python-ideas] time.wallclock() or other similar stuff The timeit module includes: if sys.platform == "win32": # On Windows, the best timer is time.clock() default_timer = time.clock else: # On most other platforms the best timer is time.time() default_timer = time.time +1 on a platform-dependent alias to time() or clock() +1 on calling it "timer" -0 on calling it "wall_clock" -- Steven _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Alexander Belopolsky wrote:

On Mon, Nov 1, 2010 at 9:50 PM, Steven D'Aprano wrote: ..

...

The timeit module includes:

if sys.platform == "win32": # On Windows, the best timer is time.clock() default_timer = time.clock else: # On most other platforms the best timer is time.time() default_timer = time.time

Doesn't this mean that the requested functionality is already available as

from timeit import default_timer

?

Well, yes, it does, but: (1) How many people would think to look in timeit for this function? Both you and Kristján were apparently surprised that it already exists, and I'd bet money that you weren't the only ones. timeit seems to be more of an application than a library (although I acknowledge the border between the two is fuzzy), and people don't think about using it as a library. (2) The time module is the natural place to look for time-related functions. It would be nicer if timeit could import the default timer from time: from time import timer as default_timer # or wall_clock if you prefer (3) The default_timer is an implementation detail of timeit. It could change, or disappear, or be renamed. You'll note it isn't documented: http://docs.python.org/library/timeit.html (4) I started off thinking that we should just document timer (wall_clock) as an alias to one of time() or clock(), but I changed my mind. That's an implementation detail that we should be free to change in the future. For the sake of information hiding, we shouldn't promise that the timer will be one of time.clock() or time.time(). Who knows, maybe there are (or will be someday) supported platforms where neither choice is appropriate, and the timer needs to be something else? -- Steven

On 11/1/2010 11:38 PM, Steven D'Aprano wrote:

(1) How many people would think to look in timeit for this function? Both you and Kristján were apparently surprised that it already exists, and I'd bet money that you weren't the only ones. timeit seems to be more of an application than a library (although I acknowledge the border between the two is fuzzy), and people don't think about using it as a library.

(2) The time module is the natural place to look for time-related functions. It would be nicer if timeit could import the default timer from time:

from time import timer as default_timer # or wall_clock if you prefer

(3) The default_timer is an implementation detail of timeit. It could change, or disappear, or be renamed. You'll note it isn't documented:

http://docs.python.org/library/timeit.html

(4) I started off thinking that we should just document timer (wall_clock) as an alias to one of time() or clock(), but I changed my mind. That's an implementation detail that we should be free to change in the future. For the sake of information hiding, we shouldn't promise that the timer will be one of time.clock() or time.time(). Who knows, maybe there are (or will be someday) supported platforms where neither choice is appropriate, and the timer needs to be something else?

+1 for timer in time module from me too. Having two time functions in time of opposite ratings on different platforms has always (13 years or whenever there became two) seemed like a wart to me. -- Terry Jan Reedy

If you're looking for new function names, I'd suggest a pair of functions called real_time() and cpu_time(). -- Greg

On 2 November 2010 11:35, Antoine Pitrou wrote:

On Tue, 02 Nov 2010 12:50:57 +1100 Steven D'Aprano wrote:

...

+1 on a platform-dependent alias to time() or clock() +1 on calling it "timer"

"time.timer()" is much too close to "time.time()".

I'd agree with this. I'm actually +1 on the original time.wallclock(), wall time is a common concept, so having the word "wall" in it's api seems very natural to me. .walltime() would probably work as well. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

On Tue, 02 Nov 2010 13:43:04 +0000 Rob Cliffe wrote:

I beg to differ. Seeing "wall clock" just confused me - my reaction was what the ..... is he talking about? Even when I understood it, it didn't seem a very appropriate name - I would have found something like "system clock" or "system time" more intelligible. Whereas "timer" is a very familiar concept (in computing, and in life in general). And I think most people are familiar with time.time(), so will recognize that time.timer() is something different. Though I agree it would be better if the names were more different.

I share this point of view. "wallclock" is really misleading, it simply does not tell what the object is, let's one guess something totally different; and what about its purpose? (also think at non-english speakers). Imo, "timer" is exactly the proper term -- the issue due to proximity with "time" is real, but far less important. Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com

On 2010-11-02 16:17, James Noble wrote:

On Nov 2, 2010, at 11:02 AM, spir wrote:

...

Imo, "timer" is exactly the proper term -- the issue due to proximity with "time" is real, but far less important.

How about "stopwatch"

With that name, I would expect a "proper" stopwatch object with "get", "start", "stop" and "reset" methods. Not just an alias for time.time or time.clock. I wouldn't mind seeing such an object in the stdlib, but it is easy enough to define in terms of the function that is actually proposed. For example: from time import timer # the new function class stopwatch(object): def __init__(self, t=0.0): self._value = t self._started = None def get(self): s = self._started if s is not None: return self._value + timer() - s return self._value def reset(self, t=0.0): self._value = t if self._started is not None: self._started = timer() def is_running(self): return self._started is not None def start(self): if self._started is None: self._started = timer() def stop(self): s = self._started if s is not None: self._value += timer() - s self._started = None value = property(get, reset, reset) running = property(is_running, None, stop) @running.setter def running(self, value): if value: if self._started is None: self._started = timer() else: s = self._started if s is not None: self._value += timer() - s self._started = None Oh, and +1 for the proposed function - I don't really care what it's called. - Jacob

On 02/11/2010 15:35, Antoine Pitrou wrote:

On Tue, 2 Nov 2010 16:02:47 +0100 spir wrote:

...

Imo, "timer" is exactly the proper term I'm not sure it's the proper term. A timer is often a countdown with a callback. See for example threading.Timer and signal.setitimer.

...

the issue due to proximity with "time" is real, but far less important. I think it would be too easy to use one instead of the other, and get strange semantics (both count in seconds but with slightly different characteristic).

Regards

Antoine.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Well, how about "clock"? "time.clock()" seems quite evocative to me. Best wishes Rob Cliffe

Rob Cliffe wrote:

Whereas "timer" is a very familiar concept (in computing, and in life in general).

However, it suggests a factory function that returns some kind of object that performs timing, rather than simply returning a time. -- Greg

2010/11/2 M.-A. Lemburg :

You might want to look at the systimes.py module that comes with pybench (see Tools/pybench). This already provides a cross-platform way of accessing high accuracy timers for benchmarking and the like.

For obvious reasons this tries to measure run-time, though, and not elapsed time.

I think MAL answered the naming question without even realising it: time.elapsed_time(start_time=0) Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On 03/11/2010 02:41, Michael Foord wrote:

On 2 November 2010 22:17, Nick Coghlan mailto:ncoghlan@gmail.com> wrote:

2010/11/2 M.-A. Lemburg mailto:mal@egenix.com>: > You might want to look at the systimes.py module that comes with pybench > (see Tools/pybench). This already provides a cross-platform way of > accessing high accuracy timers for benchmarking and the like. > > For obvious reasons this tries to measure run-time, though, and not > elapsed time.

I think MAL answered the naming question without even realising it:

time.elapsed_time(start_time=0)

I'm +1 on the functionality and either elapsed_time or wallclock is fine with me.

Perhaps the patch author should decide...

And deprive us of the chance to bikeshed? :-)

On Tue, Nov 2, 2010 at 6:17 PM, Nick Coghlan wrote:

2010/11/2 M.-A. Lemburg :

...

You might want to look at the systimes.py module that comes with pybench (see Tools/pybench). This already provides a cross-platform way of accessing high accuracy timers for benchmarking and the like.

For obvious reasons this tries to measure run-time, though, and not elapsed time.

I think MAL answered the naming question without even realising it:

time.elapsed_time(start_time=0)

+1 from me. Geremy Condra