[Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

Cameron Simpson cs at zip.com.au
Wed Apr 4 01:38:24 CEST 2012


On 03Apr2012 15:08, Ethan Furman <ethan at stoneleaf.us> wrote:
| Cameron Simpson wrote:
| > get_clock already has two arguments - you can optionally hand it a clock
| > list - that's used by monotonic_clock() and hires_clock().
| 
| def get_clock(*flags, *, clocklist=None):

I presume that bare "*," is a typo. Both my python2 and python3 commands
reject it.

[...]
|      wanted = 0
|      for flag in flags:
|          wanted |= flag
[...]

I could do this. I think I'm -0 on it, because it doesn't seem more
expressive to my eye than the straight make-a-bitmask "|" form.
Other opinions?

| Would need to make *flags change to the other *_clock functions.

Yep.

| > The return of None is very deliberate. I _want_ user specified fallback
| > to be concise and easy. The example:
| >   clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC)
| 
| Which would become:
| clock = get_clock(MONOTONIC, HIGHRES) or get_clock(MONOTONIC)
| 
| +1 to returning None
| 
| > Exceptions are all very well when there is just one thing to do: parse
| > this or fail, divide this by that or fail. If fact they're the very
| > image of "do this one thing or FAIL". They are not such a good match for do
| > this thing or that thing or this other thing.

Another thought that occurred in the shower was that get_clock() et al
are inquiry functions, and returning None is very sensible there.

monotonic() et al are direct use functions, which should raise an exception
if unavailable so that code like:

  t0 = monotonic()
  .......
  t1 = monotonic()

does not become littered with checks for special values like None.

I consider this additional reason to return None from get_clock().

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

DON'T DRINK SOAP! DILUTE DILUTE! OK!
        - on the label of Dr. Bronner's Castile Soap


More information about the Python-Dev mailing list