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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4