[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review (original) (raw)

Larry Hastings larry at hastings.org
Thu Feb 16 16:29:40 CET 2012

On 02/15/2012 08:12 PM, Guido van Rossum wrote:

On Wed, Feb 15, 2012 at 7:28 PM, Larry Hastings<larry at hastings.org> wrote:

I fixed this in trunk last September (issue 12904); os.utime now preserves all the precision that Python currently conveys. So, essentially you fixed this particular issue without having to do anything as drastic as the proposed PEP...

I wouldn't say that. The underlying representation is still nanoseconds, and Python only preserves roughly hundred-nanosecond precision. My patch only ensures that reading and writing atime/mtime looks consistent to Python programs using the os module. Any code that examined the nanosecond-precise values from stat()--written in Python or any other language--would notice the values didn't match.

I'm definitely +1 for extending Python to represent nanosecond precision ctime/atime/mtime, but doing so in a way that permits seamlessly adding more precision down the road when the Linux kernel hackers get bored again and add femtosecond resolution. (And then presumably attosecond resolution four years later.) I haven't read 410 yet so I have no opinion on it.

I wrote a patch last year that adds new Decimal ctime/mtime/atime fields to the output of stat, but it's a horrific performance regression (os.stat is 10x slower) and the reviewers were ambivalent so I've let it rot. Anyway I now agree that we should improve the precision of datetime objects and use those instead of Decimal. (But not timedeltas--ctime/mtime/atime are absolute times, not deltas.)

/arry

More information about the Python-Dev mailing list