On Sat, 14 Oct 2017 10:49:11 +0300 Serhiy Storchaka <storch...@gmail.com> wrote:
> 13.10.17 17:12, Victor Stinner пише: > > I would like to add new functions to return time as a number of > > nanosecond (Python int), especially time.time_ns(). > > > > It would enhance the time.time() clock resolution. In my experience, > > it decreases the minimum non-zero delta between two clock by 3 times, > > new "ns" clock versus current clock: 84 ns (2.8x better) vs 239 ns on > > Linux, and 318 us (2.8x better) vs 894 us on Windows, measured in > > Python. > > > > The question of this long email is if it's worth it to add more "_ns" > > time functions than just time.time_ns()? > > > > I would like to add: > > > > * time.time_ns() > > * time.monotonic_ns() > > * time.perf_counter_ns() > > * time.clock_gettime_ns() > > * time.clock_settime_ns() > > > > time(), monotonic() and perf_counter() clocks are the 3 most common > > clocks and users use them to get the best available clock resolution. > > clock_gettime/settime() are the generic UNIX API to access these > > clocks and so should also be enhanced to get nanosecond resolution. > > I don't like the idea of adding a parallel set of functions. > > In the list of alternatives in PEP 410 there is no an idea about fixed > precision float type with nanoseconds precision. It can be implemented > internally as a 64-bit integer, but provide all methods required for > float-compatible number. It would be simpler and faster than general > Decimal. I agree a parallel set of functions is not ideal, but I think a parallel set of functions is still more appropriate than a new number type specific to the time module. Also, if you change existing functions to return a new type, you risk breaking compatibility even if you are very careful about designing the new type. Regards Antoine. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/