[Python-Dev] PEP: New timestamp formats

[Antoine Pitrou]

On Thu, 2 Feb 2012 23:07:28 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> We can't add new fields to the stat tuple anyway - it breaks tuple
> unpacking.

I don't think that's true. The stat tuple already has a varying number
of fields: http://docs.python.org/dev/library/os.html#os.stat

“For backward compatibility, the return value of stat() is also
accessible as a tuple of *at least* 10 integers [...] More items may be
added at the end by some implementations.” (emphasis mine)

So at most you could tuple-unpack os.stat(...)[:10].

(I've never seen code tuple-unpacking a stat tuple, myself. It sounds
quite cumbersome to do so.)

> >>> 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).

But that implementation detail will be visible to the user, including
when combining the result with other numbers (as Decimal "wins" over
float and int). IMHO it wouldn't be silly to make it explicit.

I think "hires" may confuse people into thinking the time source
has a higher resolution, whereas it's only the return type.
Perhaps it's just a documentation issue, though.

Regards

Antoine.