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

[Victor Stinner]

Le 04/04/2012 02:33, Steven D'Aprano a écrit :
> 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.

Oh, I just "rewrote" the PEP before reading your email. Sorry for the 
noise with this PEP :-) I just read again all emails related to this PEP 
to complete the PEP. The PEP should now list all proposed API designs. I 
hope that I did not forget anything.

I failed to propose a consistent and clear API because I (and Guido!) 
wanted to fallback to the system clock. Falling back to the system clock 
is a problem when you have to define the function in the documentation 
or if you don't want to use the system clock (but do something else) if 
no monotonic clock is available.

So I rewrote the PEP to simplify it:

  * Don't fallback to system clock: time.monotonic() is always monotonic 
(cannot go backward), but it is not always available. You have to write 
a classic try/except ImportError which has a nice advantage: your 
program will work on Python older than 3.3 ;-)

  * Remove the time.perf_counter() function (it was called 
time.highres() before). "highres" notion was confusing. I only wrote the 
function to expose QueryPerformanceCounter (while it was already 
accessible using os.clock()). The function was not well defined. Another 
PEP should be written or at least the subject should be discussed after 
the PEP 418 (monotonic clock).

  * Rename time.steady() to time.monotonic(), again :-)

> 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 read most emails and I can say that:

  * There is a need for a monotonic clock
  * Most people prefer to handle explicitly the fallback if no monotonic 
clock is available
  * Most people don't want to call the new function "steady" because it 
stands for something different

> I propose for Python 3.3:
>
> 1) the os module should expose lightweight wrappers around whatever
> clocks the operating system provides;

Python 3.3 has already time.clock_gettime() and time.clock_getres() with 
CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW, CLOCK_HIGHRES.

mach_absolute_time() and GetTickCount/GetTick64 are not available yet.

> 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);

Many applications already implement their own "monotonic" clock". Some 
libraries provide also such clock for Python. On UNIX, it's always using 
clock_gettime(MONOTONIC). On Windows, it's sometimes GetTickCount, 
sometimes QueryPerformanceCounter. On Mac OS X, it's always 
mach_absolute_time(). I didn't find a library supporting Solaris.

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

In the last version of my PEP, time.monotonic() is simply defined as "a 
monotonic clock (cannot go backward)". There is no more "... best ..." 
in its definition.

Victor