I'd like to have time.time_ns() -- this is most parallel to st_mtime_ns.

On Sun, Oct 15, 2017 at 2:59 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
> Might it make more sense to have a parallel *module* that works with a different base data type rather than parallel functions within the existing API?

I asked about adding new functions to 4 different modules: os, resource, signal, time.

For example, I dislike the idea of having os and os_ns modules. We already have os.stat() which returns time as seconds and nanoseconds (both at the same time). There is also os.utime() which accepts time as seconds *or* nanoseconds: os.utime (path, times=seconds) or os.utime(path, ns=nanoseconds).

If we had a time_ns module, would it only contain 4 clocks or does it have to duplicate the full API? If yes, it is likely to be a mess to maintain them. How will user choose between time and time_ns? What if tomorrow clocks get picosecond resolution? (CPU TSC also has sub-nanosecond resolution, but OS API uses timespec, 1 ns res.) Add a third module?

I prefer to leave all "time functions" in the "time module".

For example, I don't think that we need to add time.nanosleep() or time.sleep_ns(), since the precision loss starts after a sleep of 104 days. Who cares of 1 nanosecond after a sleep of 104 days?

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/




--
--Guido van Rossum (python.org/~guido)