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

Antoine Pitrou solipsis at pitrou.net
Thu Feb 2 14:20:07 CET 2012

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"). "hires", "hiprec" (for "high precision") or "fullprec" (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.

More information about the Python-Dev mailing list