[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Thu Feb 16 11:14:57 CET 2012
- Previous message: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
- Next message: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Am 16.02.2012 10:51, schrieb Victor Stinner:
2012/2/16 "Martin v. Löwis" <martin at 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}timens fields and os.utimens().
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.
I'm -1 on adding these APIs, also. Since Python 3.3 is not released yet, it's not too late to revert them.
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.
I'm wondering what use cases utimensat and futimens have that are not covered by utime/utimes (except for the higher resolution).
Keeping the "ns" in the name but not doing nanoseconds would be bad, IMO.
For sigtimedwait, accepting float is indeed the right thing to do.
In the long run, we should see whether using 128-bit floats is feasible.
Regards, Martin
- Previous message: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
- Next message: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]