> There seem to be a few competing features for clocks that people want: > > - monotonic - never going backward at all > - high resolution
These features look to be exclusive on Windows. On other platforms, it looks like monotonic clocks are always the most accurate clocks. So I don't think that we need to be able to combine these two "flags". > - no steps You mean "not adjusted by NTP"? Except CLOCK_MONOTONIC on Linux, no monotonic clock is adjusted by NTP. On Linux, there is CLOCK_MONOTONIC_RAW, but it is only available on recent Linux kernel (2.6.28). Do you think that it is important to be able to refuse a monotonic clock adjusted by NTP? What would be the use case of such truly steady clock? -- The PEP 418 tries to expose various monotonic clocks in Python with a simple API. If we fail to agree how to expose these clocks, e.g. because there are major differences between these clocks, another solution is to only expose low-level function. This is already what we do with the os module, and there is the shutil module (and others) for a higher level API. I already added new "low-level" functions to the time module: time.clock_gettime() and time.clock_getres(). > Of course you can provide some convenient-with-fallback function that > will let people do this in one hit without the need for "T", but it > should not be the base facility offered. The base should let people > request their feature set and inspect what is supplied. The purpose of such function is to fix programs written with Python < 3.3 and using time.time() whereas a monotonic would be the right clock (e.g. implement a timeout). Another concern is to write portable code. Python should help developers to write portable code, and time.monotonic(fallback=False) is not always available (and may fail). Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
