[Python-Dev] Proposing an alternative to PEP 410

[Victor Stinner]

I rejected datetime.datetime because I want to get nanosecond
resolution for time and os modules, not only for the os module. If we
choose to only patch the os module (*stat() and *utime*() functions),
datetime.datetime would be meaningful (e.g. it's easier to format
datetime for an human, than a Epoch timestamp).

I don't think that it's a real issue that datetime is not fully
compatible with float. If os.stat() continues to return float by
default, programs asking explicitly for datetime would be prepared to
handle this type. I have the same rationale with Decimal :-) I don't
think that there is a need to support datetime+int or datetime-float,
there is already the timedelta type which is well defined.

For os.stat(), you should use the UTC timezone, not a naive datetime.

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

What is a stat-like timestamp? Which functions are concerned?

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

A global switch to get timestamps as datetime or Decimal would break
libraries and programs unable to handle these types. I prefer adding
an argument to os.*stat() functions to avoid border effects. Read
also:
http://www.python.org/dev/peps/pep-0410/#add-a-global-flag-to-change-the-timestamp-type

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

We may choose a different solution for the os.stat()/os.utime() and
for the others functions (see the PEP 410 for the full list). But I
would prefer an unified solution to provide nanosecond resolution in
all modules. It would avoid to have to support two new types for
example.

Victor