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