Author pitrou
Recipients belopolsky, eric.araujo, kristjan.jonsson, michael.foord, pitrou
Date 2010-11-01.18:09:51
SpamBayes Score 1.66533e-16
Marked as misclassified No
Message-id <1288634987.11453.9.camel@localhost.localdomain>
In-reply-to <AANLkTi=Oauu2q1z5dYembm+ARz_y3ifdYLxODq_D9F_b@mail.gmail.com>
Content
> > 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).
History
Date User Action Args
2010-11-01 18:09:53pitrousetrecipients: + pitrou, belopolsky, kristjan.jonsson, eric.araujo, michael.foord
2010-11-01 18:09:51pitroulinkissue10278 messages
2010-11-01 18:09:51pitroucreate