On Sat, Oct 14, 2017 at 11:46 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>
> On 14 October 2017 at 18:21, Antoine Pitrou <solip...@pitrou.net> wrote:
>
>> On Sat, 14 Oct 2017 10:49:11 +0300
>> Serhiy Storchaka <storch...@gmail.com>
>> 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.
>
What if we had a class, say time.time_base. The user could specify the
base units (such as "s", "ns", 1e-7, etc) and the data type ('float',
'int', 'decimal', etc.) when the class is initialized. It would then
present as methods the entire time API using that precision and data type.
Then the existing functions could internally wrap an instance of the class
where the base units are "1" and the data type is "float". That way the
user could pick the representation most appropriate for their use-case,
rather than python needing who knows how many different time formats for .
The other advantage is that third-party module could potentially subclass
this with additional options, such as an astronomy module providing an
option to choose between sidereal time vs. solar time, without having to
duplicate the entire API.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
