[Python-Dev] Proposing an alternative to PEP 410

Thu Feb 23 22:28:14 CET 2012

I've been meditating on the whole os.stat mtime representation thing.
Here's a possible alternative approach.
* Improve datetime.datetime objects so they support nanosecond resolution,
 in such a way that it's 100% painless to make them even more precise in
 the future.
* Add support to datetime objects that allows adding and subtracting ints
 and floats as seconds. This behavior is controllable with a flag on the
 object--by default this behavior is off.
* Support accepting naive datetime.datetime objects in all functions that
 accept a timestamp in os (utime etc).
* Change the result of os.stat to be a custom class rather than a
 PyStructSequence. Support the sequence protocol on the custom class but
 mark it PendingDeprecation, to be removed completely in 3.5. (I can't
 take credit for this idea; MvL suggested it to me once while we were 
talking
 about this issue. Now that the os.stat object has named fields, who uses
 the struct unpacking anymore?)
* Add support for setting "stat_float_times=2" (or perhaps
 "stat_float_times=datetime.datetime" ?) to enable returning 
st_[acm]time as
 naive datetime.datetime objects--specifically, ones that allow 
addition and
 subtraction of ints and floats. The value would be similar to calling
 datetime.datetime.fromdatetime() on the current float timestamp, but
 would preserve all available precision.
* Add a new parameter to functions that produce stat-like timestamps to
 explicitly specify the type of the timestamps (float or datetime),
 as proposed in PEP 410.
I realize datetime objects aren't a drop-in replacement for floats (or 
ints).
In particular their str/repr representations are much more ornate. So I'd
expect some breakage.
Personally I think the adding/subtracting ints change is a tiny bit
smelly--but this is a practicality beating purity thing. I propose making
it non-default behavior just to minimize the effects of the change.
Similarly, I realize os.stat_float_times was always a bit of a hack, what
with it being global state and all. However the approach has the virtue of
having worked in the past.
I disagree with PEP 410's conclusions about the suitability of datetime as
a timestamp object. I think "naive" datetime objects are a perfect fit.
Specficially addressing PEP 410's concerns:
 * I don't propose doing anything about the other functions that have no
 explicit start time; I'm only proposing changing the functions that 
deal
 with timestamps. (Perhaps the right thing for epoch-less times like
 time.clock would be timedelta? But I think we can table this 
discussion
 for now.)
 * "You can't compare naive and non-naive datetimes." So what? The 
existing
 timestamp from os.stat is a float, and you can't compare floats and
 non-naive datetimes. How is this an issue?
Perhaps someone else can propose something even better,
//arry/