[Python-Dev] PEP 418 is too divisive and confusing and should be postponed
steve at pearwood.info
Wed Apr 4 02:33:53 CEST 2012
Judging by the hundreds of emails regarding PEP 418, the disagreements about
APIs, namings, and even what characteristics clocks should have, I believe
that the suggestion is too divisive (and confusing!) to be accepted or
rejected at this time.
Everyone has a different opinion, everyone believes their opinion holds for
the majority, and it isn't practical for anyone to read the entire discussion.
I propose for Python 3.3:
1) the os module should expose lightweight wrappers around whatever clocks the
operating system provides;
2) the time module should NOT provide any further clocks other than the
existing time() and clock() functions (but see point 4 below);
3) we postpone PEP 418 until there is some real-world experience with using
the os clocks from Python and we can develop a consensus of what is actually
needed rather than what people think we need (i.e. probably in 3.4);
4) if the standard library has need for a "use the best clock available, for
some definition of best, and fall back to time() if not" clock, then the time
module should do the simplest thing that could possible work, flagged as a
from os import bestclock as _bestclock
_bestclock = time
This can always be promoted to a public function later, if necessary.
Python has worked pretty well without high res and monotonic clocks for 20
years. Let's not rush into a suboptimal design based on who can outlast
everyone else in this discussion.
More information about the Python-Dev