Message154319
| Author |
larry |
| Recipients |
larry |
| Date |
2012年02月26日.09:42:58 |
| SpamBayes Score |
7.65126e-08 |
| Marked as misclassified |
No |
| Message-id |
<1330249380.09.0.180670547793.issue14127@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Guido proposed st_atime_ns et al. I'll make an alternate proposal.
I'd like to avoid tying ourselves to ns resolution. As MvL said: "I don't want to deal with this issue *again* in my lifetime".
If all we want is to facilitate copying the exact metadata from os.stat to os.utime, then we don't really care about conveniently modifying the timestamp. So I propose we use MvL's suggestion of a tuple of ints. Either (numerator, denominator) or (seconds, fractional_numerator, fractional_denominator). (These are mentioned in PEP 410 under the heading "Tuple of ints" as options A and B respectively.) Name the fields with the suffix "_exact" (e.g. st_mtime_exact). os.stat and its ilk produce it; os.utime and its ilk consume it. If people want to monkey with the values and do math, let 'em--consenting adults. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年02月26日 09:43:00 | larry | set | recipients:
+ larry |
| 2012年02月26日 09:43:00 | larry | set | messageid: <1330249380.09.0.180670547793.issue14127@psf.upfronthosting.co.za> |
| 2012年02月26日 09:42:59 | larry | link | issue14127 messages |
| 2012年02月26日 09:42:58 | larry | create |
|