[Python-Dev] an alternative to embedding policy in PEP 418

[Cameron Simpson]

On 06Apr2012 00:27, Victor Stinner <victor.stinner at gmail.com> wrote:
| Le 06/04/2012 00:17, Cameron Simpson a écrit :
| > This is where the bitmap approach can be less confusing - the docstring
| > says "The returned clock shall have all the requested flags". It is at
| > least very predictable.
| 
| By the way, I removed ("deferred") the time.highres() function from the 
| PEP,

Chuckle; was not the whole PEP for a high res clock?

| and I try to avoid the term "steady" because no OS clock respect 
| the definition of "steady" (especially in corner cases as system 
| suspend/resume).

I can think of definitions of "steady" that I personally would accept,
and they'd accept that suspend/resume would be concealed (I guess I
would usually want - purely myself here - a clock representing system
run time; I'd go for time.time() for wall clock).

| So which flags do you want to support? (only "monotonic"?)

I'd stay with my current list, with metadata in the clock objects
indicating what _flavour_ of "steady" or "high res" they present.

| Basically, get_clock("monotonic") should give time.monotonic() whereas 

If time.monotonic() never falls back to a non-monotonic source, yes.

| get_clock() gives time.time()?

Might in theory give something better, but time.time() would always be a
valid result of nothing else seemed better to the module author. I imagine
in practice that time.time() might always use the "best" clock absent
special requirements. So you'd probably get what particular clock used to
implement time.time(), yes. (I realise this has interesting implications
for the list orders; time.time() would come _first_, but providing feature
flags to get_clock() can cause it not to be chosen when it doesn't match.)

This a reason why I think we should present (even privately only) all the
system clocks for a platform. Then you _can_ still offer highres() and
steady() with detailed qualifications in the docs as to what
considerations went into acepting a clock as highres or steady, and
therefore why some users may find them unsatisfactory i.e. under what
sort of circumstances/requirements they may not suit.

Any of the montonic()/highres()/steady() represent policy decisions by
the module author; it is just that monotonic() is easier to qualify than
the others: "never goes backwards in return value". Even though VMs and
system suspend can add depth to the arguments.

It _is_ useful for people to be able to reach for highres() or steady()
a lot of the time; they do, though, need to be able to decide if that's
sensible.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

I thought back to other headaches from my past and sneered at their
ineffectiveness.        - Harry Harrison