[issue10278] add time.wallclock() method

[Antoine Pitrou]

Antoine Pitrou <pitrou at free.fr> added the comment:

> > Well, the problem is that the "appropriate test" is not easy to guess a priori, so it would
> > be useful for the stdlib to provide the right tool for the job.
> 
> This sounds like an argument against this feature, not for it.  If it
> is hard for the application code to implement an appropriate test "a
> priori", what is the chance to get it right in stdlib?

The point of a standard library is to bring together competence and
experience to build a common ground of useful functions. If we
restricted ourselves to easy things then 75% of the stdlib should be
ripped out.

> > As for where it should live, I have no strong opinion, but it's true that the time module looks appropriate.
> 
> Having time.time and time.clock is already confusing enough.  Having
> the third function which is either the first or the second depending
> on some unspecified criterion does not strike me as a clean design.

The problem is time.clock(), since it does two wildly different things
depending on the OS.
I would suggest to deprecate time.clock() at the same time as we add
time.wallclock(). For the Unix-specific definition of time.clock(),
there is already os.times() (which gives even richer information).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________