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/
_______________________________________________
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
