Why is the PEP promoting the float type being used as the default on the new-in-3.3 APIs that were added explicitly to provide nanosecond level resolution that cannot be represented by a float?<div><br></div><div>The *new* APIs should default to the high precision return value (be that datetime/timedelta or decimal).</div>
<div><br></div><div>-gps<br><br><div class="gmail_quote">On Fri, Feb 3, 2012 at 11:32 AM, Jeffrey Yasskin <span dir="ltr"><<a href="mailto:jyasskin@gmail.com">jyasskin@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 class="im">On Fri, Feb 3, 2012 at 11:17 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
> On Fri, 3 Feb 2012 11:04:14 -0800<br>
> Jeffrey Yasskin <<a href="mailto:jyasskin@gmail.com">jyasskin@gmail.com</a>> wrote:<br>
>> On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>> > datetime.datetime<br>
>> ><br>
>> > - real problem with the idea is that not all timestamps can be easily<br>
>> > made absolute (e.g. some APIs may return "time since system started"<br>
>> > or "time since process started")<br>
>><br>
>> I think this is an argument for returning the appropriate one of<br>
>> datetime or timedelta from all of these functions: users need to keep<br>
>> track of whether they've got an absolute time, or an offset from an<br>
>> unspecified starting point, and that's a type-like distinction.<br>
><br>
> Keep in mind timedelta has a microsecond resolution. The use cases<br>
> meant for the PEP imply nanosecond resolution (POSIX' clock_gettime(),<br>
> for example).<br>
<br>
</div>Yes, I think someone had noted that datetime and timedelta would need<br>
to be extended to support nanosecond resolution.<br>
<div class="im"><br>
>> A plain number of seconds is superficially simpler, but it forces more<br>
>> complexity onto the user, who has to track what that number<br>
>> represents.<br>
><br>
> If all you are doing is comparing timestamps (which I guess is most of<br>
> what people do with e.g. st_mtime), a number is fine.<br>
<br>
</div>Sure. I don't think the argument for datetime is totally convincing,<br>
just that it's stronger than the PEP currently presents.<br>
<div class="im"><br>
> If you want the current time and date in a high-level form, you can<br>
> already use datetime.now() or datetime.utcnow() (which "only" has<br>
> microsecond resolution as well :-)). We don't need another way to spell<br>
> it.<br>
<br>
</div>Whoops, yes, there's no need to extend time() to return a datetime.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/greg%40krypto.org" target="_blank">http://mail.python.org/mailman/options/python-dev/greg%40krypto.org</a><br>
</div></div></blockquote></div><br></div>