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

[Steven D'Aprano]

On Wed, Apr 04, 2012 at 03:28:34AM +0200, Victor Stinner wrote:
> 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 think the PEP is a good, important PEP, and thank you for being the 
PEP's champion. But in my opinion, this is too big to rush it and risk 
locking in a sub-standard API for the next decade or two.


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

Why does it already have these things when the PEP is not accepted? 

(This is not a rhetorical question, perhaps there is a good reason why 
these have been added independently of the PEP.)

If I remember correctly, Guido earlier mentioned that he only wanted to 
see one or two (I forget which) new clocks, and I see in 3.3.0a1 there 
are already at least five new clocks:

monotonic or clock_gettime(CLOCK_MONOTONIC)  # Are these the same thing?
wallclock
clock_gettime(CLOCK_PROCESS_CPUTIME_ID)
clock_gettime(CLOCK_REALTIME)
clock_gettime(CLOCK_THREAD_CPUTIME_ID)

plus the old ways, time.time and time.clock. (Neither of which seems 
to have a clock-id.)


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

That will make potentially 10 different clocks in the time module.


It may be that, eventually, Python should support all these ten 
different clocks. (Personally, I doubt that the average Python 
programmer cares about the difference between time() and clock(), let 
alone another eight more.) But there's no rush. I think we should start 
by supporting OS-specific clocks in the os module, and then once we have 
some best-practice idioms, we can promote some of them to the time 
module.


-- 
Steven