homepage

> > 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).