Message120149
> > 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). |
|
Date |
User |
Action |
Args |
2010-11-01 18:09:53 | pitrou | set | recipients:
+ pitrou, belopolsky, kristjan.jonsson, eric.araujo, michael.foord |
2010-11-01 18:09:51 | pitrou | link | issue10278 messages |
2010-11-01 18:09:51 | pitrou | create | |
|