On 30Mar2012 13:52, Guido van Rossum <gu...@python.org> wrote: | (In fact, this even argues against having both the timer with fallback | and the timer without fallback. So maybe we should just have a single | timer function, *with* fallback, and a separate mechanism to inquire | its properties.)
Well, you should be able to know what kind of clock you're getting. But what do to if you don't get a satisfactory one? There's then no way for ask for an alternative; you don't get to control the fallback method, for example. I've come to the opinion that the chosen approach is wrong, and suggest a better one. There seem to be a few competing features for clocks that people want: - monotonic - never going backward at all - high resolution - no steps and only a few, fortunately. I think you're doing this wrong at the API level. People currently are expecting to call (for example) time.monotonic() (or whatever) and get back "now", a hopefully high resolution float. Given the subtlety sought for various purposes, people should be calling: T = time.getclock(flags) and then later calling: T.now() to get their float. That way people can: - request a set of the three characteristics above - inspect what they get back (it should have all the requested flags, but unrequested flags may be set or not depending on the underlying facility) Obviously this should return None or raise an exception if the flag set can't be met. Then users can request a less featured clock on failure, depending on what aspects of the clock are most desirable to their use case. Or of course fail if fallback is not satisfactory. Of course you can provide some convenient-with-fallback function that will let people do this in one hit without the need for "T", but it should not be the base facility offered. The base should let people request their feature set and inspect what is supplied. Cheers, -- Cameron Simpson <c...@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ Time is nature's way of keeping everything from happening at once. _______________________________________________ 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