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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
