cs at zip
Apr 2, 2012, 3:44 PM
Views: 303
Permalink
|
|
Re: an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
[In reply to]
|
|
On 03Apr2012 07:38, I wrote:
| On 02Apr2012 13:37, Victor Stinner <victor.stinner [at] gmail> wrote:
| | Should I use
| | MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and
| | high-resolution clock?
|
| Note that you don't need to provide a clock list at all; get_clock(0
| will use ALL_CLOCKS 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> 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
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
|
