> > > C. Make st_mtime a floating point number. This won't offer nanosecond > > > resolution, as C doubles are not dense enough. > > > > This is the most Pythonic approach. > > -1 > > This then locks Python into a specific bit-description notion of a double > in order to get the appropriate number of significant digits to describe > time sufficiently. Embedded/portable processors may not support the > notion of an IEEE double. > > In addition, timers get increasingly dense as computers get faster. Thus, > doubles may work for nanoseconds, but will not be sufficient for > picoseconds. > > If the goal is a field which never has to be changed to support any amount > of time, the value should be "infinite precision". At that point, a > Python Long used in some tuple representation of fixed-point arithmetic > springs to mind. ie. (<long>, <bit of fractional point>) I'm sorry, but I really don't see the point of wanting to record file mtimes all the way up to nanosecond precision. What would it mean? Most clocks are off by a few seconds at least anyway. Python has represented time as Pythin floats (implemented as C doubles) all its life long and it has served us well. --Guido van Rossum (home page: http://www.python.org/~guido/)
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