[Python-Dev] PEP: New timestamp formats (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Thu Feb 2 14:07:28 CET 2012

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

More information about the Python-Dev mailing list