[Python-Dev] Proposing an alternative to PEP 410 (original) (raw)

Victor Stinner victor.stinner at gmail.com
Thu Feb 23 23:35:24 CET 2012

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

More information about the Python-Dev mailing list