Antoine Pitrou <pit...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue10278> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com