[Python-Dev] PEP: New timestamp formats

[Nick Coghlan]

On Thu, Feb 2, 2012 at 10:16 PM, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> If we only support int, float and Decimal, we don't need to add a new
> protocol, hardcoded functions are enough :-)

Yup, that's why your middle-ground approach didn't make any sense to
me. Returning Decimal when a flag is set to request high precision
values actually handles everything (since any epoch related questions
only arise later when converting the decimal timestamp to an absolute
time value).

I think a protocol based approach would be *feasible*, but also
overkill for the specific problem we're trying to handle (i.e.
arbitrary precision timestamps). If a dependency from time and os on
the decimal module means we decide to finally incorporate Stefan's
cdecimal branch, I consider that a win in its own right (there are
some speed hacks in decimal that didn't fair well in the Py3k
transition because they went from being 8-bit str based to Unicode str
based. They didn't *break* from a correctness point of view, but my
money would be on they're being pessimisations now instead of
optimisations).

>>> os.stat: add new fields
>>> -----------------------
> New fields can be optional (add a flag to get them), but I don't like
> the idea of a structure with a variable number of fields, especially
> because os.stat() structure can be used as a tuple (get a field by its
> index).
>
> Patching os.stat() doesn't solve the problem for the time module anyway.

We can't add new fields to the stat tuple anyway - it breaks tuple
unpacking. Any new fields would have been accessible by name only
(which poses its own problems, but is a solution we've used before -
in the codecs module, for example).

As you say though, this was never going to be adequate since it
doesn't help with the time APIs.

>>> Add an argument to change the result type
>>> -----------------------------------------
>>
>> There should also be a description of the "set a boolean flag to
>> request high precision output" approach.
>
> You mean something like: time.time(hires=True)? Or time.time(decimal=True)?

Yeah, I was thinking "hires" as the short form of "high resolution",
but it's a little confusing since it also parses as the word "hires"
(i.e. "hire"+"s"). "hi_res", "hi_prec" (for "high precision") or
"full_prec" (for "full precision") might be better.

I don't really like "decimal" as the flag name, since it confuses an
implementation detail (using decimal.Decimal) with the design intent
(preserving the full precision of the underlying timestamp).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia