[Python-Dev] PEP 418 is too divisive and confusing and should be postponed
steve at pearwood.info
Wed Apr 4 10:09:40 CEST 2012
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?
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
More information about the Python-Dev