On 02/15/2012 08:12 PM, Guido van Rossum wrote:
On Wed, Feb 15, 2012 at 7:28 PM, Larry Hastings<la...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
