[Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Steven D'Aprano]

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 
private function:

try:
     from os import bestclock as _bestclock
except ImportError:
     _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.



-- 
Steven