On 02Apr2012 14:59, Glenn Linderman <v+pyt...@g.nevcal.com> wrote: | On 4/2/2012 2:40 PM, Nick Coghlan wrote: | > On Tue, Apr 3, 2012 at 3:44 AM, Glenn Linderman<v+pyt...@g.nevcal.com> wrote: | >> > One thing I don't like about the idea of fallback being buried under some | >> > API is that the efficiency of that API on each call must be less than the | >> > efficiency of directly calling an API to get a single clock's time. | > No, that's a misunderstanding of the fallback mechanism. The fallback | > happens when the time module is initialised, not on every call. Once | > the appropriate clock has been selected during module initialisation, | > it is invoked directly at call time. | | I would hope that is how the fallback mechanism would be coded, but I'm | pretty sure I've seen other comments in this thread that implied | otherwise. But please don't ask me to find them, this thread is huge.
The idea of falling back to different clocks on the fly on different calls got a bit of a rejection I thought. A recipe for clock inconsitency whatever the failings of the current clock. Cheers, -- Cameron Simpson <c...@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ We need a taxonomy for 'printing-that-is-no-longer-printing.' - overhead by WIRED at the Intelligent Printing conference Oct2006 _______________________________________________ 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
