2012/2/16 "Martin v. Löwis" <mar...@v.loewis.de>:
>> Maybe an alternative PEP could be written that supports the filesystem
>> copying use case only, using some specialized ns APIs? I really think
>> that all you need is st_{a,c,m}time_ns fields and os.utime_ns().
>
> I'm -1 on that, because it will make people write complicated code.Python 3.3 *has already* APIs for nanosecond timestamps: os.utimensat(), os.futimens(), signal.sigtimedwait(), etc. These functions expect a (seconds: int, nanoseconds: int) tuple. We have to decide before the Python 3.3 release if this API is just fine, or if it should be changed. After the release, it will be more difficult to change the API. If os.utimensat() expects a tuple, it would be nice to have a function getting time as a tuple, like the C language has the clock_gettime() function to get a timestamp as a timespec structure. During the discussion, many developers wanted a type allowing to do arithmetic operations like t2-t1 to compute a delta, or t+delta to "set" a timezone. It is possible to do arithmetic on a tuple, but it is not practical and I don't like a type with a fixed resolution (in some cases you need millisecond, microseconds or 100 ns resolution). If you consider that the float loss of precision is not an issue for nanoseconds, we should use float for os.utimensat(), os.futimens() and signal.sigtimedwait(), just for consistency. 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
