Nick Coghlan schrieb am 14.10.2017 um 17:46: > On 14 October 2017 at 18:21, Antoine Pitrou wrote: >> On Sat, 14 Oct 2017 10:49:11 +0300 >> Serhiy Storchaka wrote: >>> 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. >> > > 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? > > That is, if folks wanted to switch to 64-bit nanosecond time, they would > use: > > * time_ns.time() > * time_ns.monotonic() > * time_ns.perf_counter() > * time_ns.clock_gettime() > * time_ns.clock_settime() > > The idea here would be akin to the fact we have both math and cmath as > modules, where the common APIs conceptually implement the same algorithms, > they just work with a different numeric type (floats vs complex numbers).
I thought of that, too. People are used to rename things on import, so this would provide a very easy way for them to switch. OTOH, I would guess that "from time import time" covers more than 90% of the use cases of the time module and it doesn't really matter if we make people change the first or the second part of that import statement... But the real point here is that the data type which the current time module deals with is really (semantically) different from what is proposed now. All functionality in the time module assumes to work with "seconds", and accepts fractions of seconds for better precision. But the common semantic ground is "seconds". That suggests to me that "nanoseconds" really fits best into a new module which clearly separates the semantics of the two data types. (That being said, I'm a big fan of fractions, so I wonder if a Fraction with a constant nano denominator wouldn't fit in here...) Stefan _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
