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
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-devUnsubscribe:
http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Locked
