<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Oct 14, 2017 at 11:46 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span class="">On 14 October 2017 at 18:21, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Sat, 14 Oct 2017 10:49:11 +0300<br>
Serhiy Storchaka <<a href="mailto:storchaka@gmail.com" target="_blank">storchaka@gmail.com</a>><br>
wrote:<br>
</span><span class=""><div><div class="m_-4217711173736225409gmail-h5">> I don't like the idea of adding a parallel set of functions.<br>
><br>
> In the list of alternatives in PEP 410 there is no an idea about fixed<br>
> precision float type with nanoseconds precision. It can be implemented<br>
> internally as a 64-bit integer, but provide all methods required for<br>
> float-compatible number. It would be simpler and faster than general<br>
> Decimal.<br>
<br>
</div></div>I agree a parallel set of functions is not ideal, but I think a parallel<br>
set of functions is still more appropriate than a new number type<br>
specific to the time module.<br>
<br>
Also, if you change existing functions to return a new type, you risk<br>
breaking compatibility even if you are very careful about designing the<br>
new type.<br></span></blockquote><div><br></div>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?</div><div class="gmail_quote"><br></div><div class="gmail_quote">That is, if folks wanted to switch to 64-bit nanosecond time, they would use:</div><div class="gmail_quote"><br></div><div class="gmail_quote">* time_ns.time()<br>
* time_ns.monotonic()<br>
* time_ns.perf_counter()<br>
* time_ns.clock_gettime()<br>
* time_ns.clock_settime()</div><div class="gmail_quote"><br></div><div class="gmail_quote">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).</div><br><div class="gmail_quote">Cheers,</div><div class="gmail_quote">Nick.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"></span></div></div></blockquote><div><br></div><div>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 .  <br><br>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.<br></div></div></div></div>