On 30Mar2012 15:21, Guido van Rossum <gu...@python.org> wrote:
| On Fri, Mar 30, 2012 at 2:43 PM, Cameron Simpson <c...@zip.com.au> wrote:
| > 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.
[...]
| I like this out-of-the-box thinking. But I'm still wondering if there
| really are enough flags for this to be worth it. If there are, great,
| the API is pretty. But if there are only 2 or 3 flag combinations that
| make actual sense, let's forget it.
There are at least three characteristics listed above. There are several
use cases described in the long discussions.
I don't think we should be saying "we will only support these 3
thought-of use cases and the others are too hard/weird/perverse/rare".
We should be saying: we can characterise clocks in these very few ways.
Ask for a clock of some kind. We will provide one (abitrarily, though
perhaps preferring higher precision) that satisfies the request if
available.
I can easily envisage calling code as simple as this:
T = getclock(T_MONOTONIC|T_HIGHRES) or getclock(T_MONOTONIC)
to do my own fallback for my own use case if we went with returning None
if there is no satisfactory clock.
If I need monotonic (for example) my code is in NO WAY helped by being
handed something that sometimes is not monotonic; to make my code
reliable I would need to act as though I wasn't getting a montonic clock
in the first place. No win there at all.
This has the following advantages:
- it removes _all_ policy from the PEP, at least at the core
- it makes things totally clear and concise at the calling end;
the clock characterists are right there in front of the reader
- policy is in the hands of the user where it belongs, and is easy to
specify into the bargain
- it avoids the horrendous ideas mooted of asking for something called
monotonic and getting sometime only mostly monotonic, and the
equivalent flavours for the other flags
- implementation of the PEP is in principle as easy as a table of
clock wrappers with the flags each supports. Loop over the table
until one matches all the requested flags, or return None.
- for higher quality of implementation you embed policy in the
convenience function, not the getclock() function
To take your suggestion of:
Another out-of-the-box idea, going back to simplicity: have just one
new function, time.hrtimer(), which is implemented using the
highest-resolution timer available on the platform, but with no strong
guarantees.
Example:
T = time.hrtimer()
which would provide the "best" hires timer. You'd give it an
optional flag argument for additional flags so that you could
request the most-hires timer matching the flags. This is like:
T = time.getclock(T_HIRES)
except that is makes clear your preferred attribute.
So internally one would have:
- clock wrappers for the platform specific facilities, with the
constructors being singletons or not as suits the facility
- a list of the wrappers with their flag sets specifiying what
clock attributes they offer
- for the .hrtimer([flags]) or .monotonic([flags]) calls they each
have their own list of the clock wrapper, ordered on most-hires
or best-monotonic, as the implementor sees fit
That gets you:
- arbitrary user case support
- convenience functions for common policies
| It *may* jump, move back, drift, change its rate, or roll
| over occasionally. We try to use the implementation that's got the
| fewest problems, but we don't try to hide its deficiencies, and
| nothing suitable exists, it may be equivalent to time.time(). If the
| times you measure are too weird, measure again. For scheduling things
| a day or more in the future, you should use time.time() instead.
Getting ugly. This is why I think we should not be offering only what
we think the user may want, especially when we offer something loose
and rubbery like this.
Instead, get the user to ask. The platform timers can all be well
characterised with respect to the flags suggested above; you only need
to tabulate what timers offer what behaviours.
By all means offer convenience functions providing common choices,
but don't make those the _only_ choices. Let the user ask for anything;
if the platform can't support it that's a pity, but leave the user the
choice of asking for less or making whatever other decision suits them.
| One issue that hasn't had enough attention: *scope* of a timer. If two
| processes running on the same machine ask for the time, do the values
| they see use the same epoch, or is the epoch dependent on the process?
| Some code I saw in timemodule.c for working around Windows clocks
| rolling over seem to imply that two processes may not always see the
| same timer value. Is there a use case where this matters?
Make the epoch available in the clock wrapper as a property. At least
then there's a mechanism for reconciling things. Don't try to mandate
something that possibly can't be mandated.
Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
My computer always does exactly what I tell it to do but sometimes I have
trouble finding out what it was that I told it to do.
- Dick Wexelblat <r...@ida.org>
_______________________________________________
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
