Showing content from http://mail.python.org/pipermail/python-dev/attachments/20120203/39038b05/attachment.html below:
<p> <br>
On Feb 3, 2012 2:59 AM, "Barry Warsaw" <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>
><br>
> On Feb 02, 2012, at 11:07 PM, Nick Coghlan wrote:<br>
><br>
> >Yup, that's why your middle-ground approach didn't make any sense to<br>
> >me. Returning Decimal when a flag is set to request high precision<br>
> >values actually handles everything (since any epoch related questions<br>
> >only arise later when converting the decimal timestamp to an absolute<br>
> >time value).<br>
><br>
> Guido really dislikes APIs where a flag changes the return type, and I agree<br>
> with him. It's because this is highly unreadable:<br>
><br>
> results = blah.whatever(True)<br>
><br>
> What the heck does that `True` do? It can be marginally better with a<br>
> keyword-only argument, but not much.</p>
<p>Victor's patch passes in the return type rather than a binary flag, thus avoiding this particular problem. </p>
<p>> I haven't read the whole thread so maybe this is a stupid question, but why<br>
> can't we add a datetime-compatible higher precision type that hides all the<br>
> implementation details? <br>
><br>
> -Barry</p>
<p>It's not a stupid question, but for backwards compatibility, what we would actually need is a version of Decimal that implicitly interoperates with binary floats. That's... not trivial. </p>
<p>Cheers,<br>
Nick<br>
--<br>
Sent from my phone, thus the relative brevity :)</p>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4