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.
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 propose for Python 3.3:
1) the os module should expose lightweight wrappers around whatever clocks the
operating system provides;
2) the time module should NOT provide any further clocks other than the
existing time() and clock() functions (but see point 4 below);
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);
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:
try:
from os import bestclock as _bestclock
except ImportError:
_bestclock = time
This can always be promoted to a public function later, if necessary.
Python has worked pretty well without high res and monotonic clocks for 20
years. Let's not rush into a suboptimal design based on who can outlast
everyone else in this discussion.
--
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
