[Python-Dev] Issue #10278 -- why not just an attribute? (original) (raw)
Victor Stinner victor.stinner at gmail.com
Tue Mar 20 10:25:13 CET 2012
- Previous message: [Python-Dev] Issue #10278 -- why not just an attribute?
- Next message: [Python-Dev] Issue #10278 -- why not just an attribute?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2012/3/20 Jim J. Jewett <jimjjewett at gmail.com>:
In http://mail.python.org/pipermail/python-dev/2012-March/117762.html Georg Brandl posted:
+ If available, a monotonic clock is used. By default, if strict is False, + the function falls back to another clock if the monotonic clock failed or is + not available. If strict is True, raise an :exc:
OSError
on error or + :exc:NotImplementedError
if no monotonic clock is available. This is not clear to me. Why wouldn't it raise OSError on error even with strict=False? Please clarify which exception is raised in which case. Passing strict as an argument seems like overkill since it will always be meaningless on some (most?) platforms. Why not just use a function attribute? Those few users who do care can check the value of time.steady.monotonic before calling time.steady(); exceptions raised will always be whatever the clock actually raises.
The clock is chosen at runtime. You might use a different clock at each call. In most cases, Python should chose a clock at the first call and reuse it for next calls.
For example, on Linux the following clocks are tested:
- clock_gettime(CLOCK_MONONOTIC_RAW)
- clock_gettime(CLOCK_MONONOTIC)
- gettimeofday()
- ftime()
Victor
- Previous message: [Python-Dev] Issue #10278 -- why not just an attribute?
- Next message: [Python-Dev] Issue #10278 -- why not just an attribute?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]