[Python-Dev] Proposing an alternative to PEP 410

[Barry Warsaw]

On Feb 23, 2012, at 01:28 PM, Larry Hastings wrote:

>* 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.

+1

>* 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.

Why conditionalize this behavior?  It should either be enabled or not, but
making it switchable on a per-object basis seems like asking for trouble.

>* Support accepting naive datetime.datetime objects in all functions that
>   accept a timestamp in os (utime etc).

+1

>* 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?)

+1

>* 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.

I personally don't much like the global state represented by
os.stat_float_times() in the first place.  Even though it also could be
considered somewhat un-Pythonthic, I think it probably would have been better
to accept an optional argument in os.stat() to determine the return value.  Or
maybe it would have been more acceptable to have os.stat(), os.stat_float(),
and os.stat_datetime() methods.

>* 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.

+1

>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.)

+1, and yeah, I think we've had general agreement about using timedeltas for
epoch-less times.

>   * "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?

Exactly.

>Perhaps someone else can propose something even better,

If we really feel like we need to make a change to support higher resolution
timestamps, this comes pretty darn close to what I'd like to see.

-Barry