[Python-Dev] Proposing an alternative to PEP 410

[Larry Hastings]

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/