New monotonic clock that tracks across system suspend
Consider the monotonic clock defined in pytime.c. Whether or not it tracks time across system suspend is implementation-defined (and not documented either). PEP 418 [1] has details along with the raw system APIs used. We could introduce two new monotonic clocks that distinguish between whether they track across system suspend or not. These clocks exist on at least Windows, macOS, and Linux. [1] https://www.python.org/dev/peps/pep-0418/#id56 — Rishav P.S.: This is my first time submitting to the Python mailing lists. Suggestions for improvement are appreciated :)
Rishav Kundu via Python-ideas writes:
Consider the monotonic clock defined in pytime.c. Whether or not it tracks time across system suspend is implementation-defined (and not documented either). PEP 418 [1] has details along with the raw system APIs used.
We could introduce two new monotonic clocks that distinguish between whether they track across system suspend or not. These clocks exist on at least Windows, macOS, and Linux.
Which clocks exist on all three platforms: tracking, non-tracking, both? What are some use cases for tracking that can't be done with a non-tracking clock? What are some use cases for non-tracking clocks that can't be done with a tracking clock? The point is, "do we really need both, or can we just add the useful one for those who need it when it exists?" Why can't this be done in a separate extension module on PyPI, distributed as wheels for platforms that support it, for users who need it?[1] If it is likely that non-core developers would create buggy implementations so it's worth having a "canonical" in-stdlib implementation, explain why (to the extent that it makes that claim plausible; you can't "prove" something like this and nobody expects you to, it's always a judgment call by the reviewers).
P.S.: This is my first time submitting to the Python mailing lists. Suggestions for improvement are appreciated :)
See questions above. :-) Nothing stops people from adding the facility as an extension module or a forked stdlib. So you need to explain why this needs to be in *every* Python, imposing additional development, documentation, and maintenance burden on an overstretched core developer community. Slight though such burden may be, it needs to be justified by a fairly large "multiplier" of convenience to the community of developers-using-Python -- the developers-of-Python have plenty of alternative tasks that have "large" multipliers. Footnotes: [1] Typically this would be answered either "a large fraction of users need it" for values of "large" > 1% ;-), or "there are industrial use cases where it is extremely difficult to get an extension module through enterprise vetting processes".
participants (2)
-
Rishav Kundu
-
Stephen J. Turnbull