On 14 October 2017 at 18:21, Antoine Pitrou <[email protected]> wrote:
> On Sat, 14 Oct 2017 10:49:11 +0300 > Serhiy Storchaka <[email protected]> > 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). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
