[Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock) (original) (raw)
Cameron Simpson cs at zip.com.au
Tue Apr 3 00:44:24 CEST 2012
- Previous message: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
- Next message: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 03Apr2012 07:38, I wrote: | On 02Apr2012 13:37, Victor Stinner <victor.stinner at gmail.com> wrote: | | Should I use | | MONTONICCLOCKS or HIRESCLOCKS when I would like a monotonic and | | high-resolution clock? || Note that you don't need to provide a clock list at all; getclock(0 | will use ALLCLOCKS by default, and hires() and monotonic() should each | have their own default list. [...] | | It would be simpler to have only one global and | | private list. [...] | The whole point is to let the user be able to control the choices to a | fair degree without platform special knowledge.
On some reflection I may lean a little more Victor's way here:
I am still very much of the opinion that there should be multiple clock lists so that hires() can offer the better hires clocks first and so forth.
However, perhaps I misunderstood and he was asking if he needed to name a list to get a hires clock etc. This intent is not to need to, via the convenience functions.
Accordingly, maybe the list names needn't be published, and may complicate the published interface even though they're one to one with the flags.
It would certainly up the ante slightly f we added more flags some time later. (For example, I think any synthetic clocks such as the caching example in the skeleton should probably have a SYNTHETIC flag. You might never ask for it, but you should be able to check for it.
(I personally suspect some of the OS clocks are themselves synthetic, but no matter...)
The flip side of this of course is that if the list names are private then the get_clock() and hires() etc functions almost mandatorially need the optional all_clocks=False parameter mooted in a sibling post; the really picky user needs a way to iterate over the available clocks to make a fine grained decision. On example would be to ask for monotonic clocks but omit synthetic ones (there's a synthetic clock in the skeleton though I don't partiularly expect one in reality - that really is better in a broader "*utils" module; I also do NOT want to get into complicated parameters to say these flags but not those flags and so forth for other metadata.
And again, an external module offering synthetic clocks could easily want to be able to fetch the existing and augument the list with its own, then use that with the get_clock() interfaces.
So in short I think:
there should be, internally at least, multiple lists for quality of returned result
there should be a way to iterate over the available clocks, probably via an all_clocks paramater instead of a public list name
Cheers,
Cameron Simpson <cs at zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/
There is hopeful symbolism in the fact that flags do not wave in a vacuum. - Arthur C. Clarke
- Previous message: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
- Next message: [Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]