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.stin...@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)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
