[Python-Dev] an alternative to embedding policy in PEP 418
cs at zip.com.au
Tue Apr 3 02:18:46 CEST 2012
On 02Apr2012 14:59, Glenn Linderman <v+python at 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+python at 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.
Cameron Simpson <cs at zip.com.au> DoD#743
We need a taxonomy for 'printing-that-is-no-longer-printing.'
- overhead by WIRED at the Intelligent Printing conference Oct2006
More information about the Python-Dev