Message76344
| Author |
belopolsky |
| Recipients |
Neil Muller, andersjm, belopolsky, davidfraser, hodgestar, tebeka, vstinner, werneck |
| Date |
2008年11月24日.17:33:05 |
| SpamBayes Score |
3.1249238e-05 |
| Marked as misclassified |
No |
| Message-id |
<d38f5330811240933x49bd9163vaf9b56f7ec4259b9@mail.gmail.com> |
| In-reply-to |
<1227546823.91.0.931359618478.issue2736@psf.upfronthosting.co.za> |
| Content |
On Mon, Nov 24, 2008 at 12:13 PM, STINNER Victor <report@bugs.python.org> wrote:
..
> Hum, it's maybe not possible to choose between integer and float. Why
> not supporting both? Example:
> - totimestamp()->int: truncate microseconds
> - totimestamp(microseconds=True)->float: with microseconds
I would still prefer totimestamp()->(int, int) returning (sec, usec)
tuple. The important benefit is that such totimestamp() will not
loose information and will support more formats than either of your
->int or ->float variants. The ->int can then be spelt simply as
totimestamp()[0] and on systems with numpy (which is likely for users
that deal with floats a lot), totimestamp(microseconds=True) is simply
dot([1, 1e-6], totimestamp()). (and s,us = totimestamp(); return s +
us * 1e-6 is not that hard either.) |
|