Message152317
| Author |
vstinner |
| Recipients |
Alexander.Belopolsky, Arfrever, belopolsky, ericography, jcea, khenriksson, larry, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rhettinger, rosslagerwall, skrah, vstinner |
| Date |
2012年01月30日.13:14:20 |
| SpamBayes Score |
4.5655307e-10 |
| Marked as misclassified |
No |
| Message-id |
<CAMpsgwZvBkzAqNsBJLextiT2kPdZZ-fsFB1GrziEA7kQ_pX72g@mail.gmail.com> |
| In-reply-to |
<1327893719.5.0.977023684576.issue11457@psf.upfronthosting.co.za> |
| Content |
> I think that one of available types of time values returned by os.stat() should allow to directly pass these values to os.futimens() and os.utimensat(), which expect (time_sec, time_nsec) tuples.
Oh, I realized that these two functions were added to Python 3.3, so
it is not too late to change their API. I would prefer to limit the
number of timestamp formats: Python 3.2 has float and datetime, I (and
Martin) propose to add Decimal to Python 3.3 (to get nanosecond
resolution). (sec, nsec) is a new format, except if Python 3.2 has
already functions expecting such tuple?
I know that the underlying C function expects a timespec structure,
but Python can try to use a higher level API, isn't it?
Decimal is more practical than a tuple because you can just write :
t2-t1 to compute a time delta. Decimal has other advantages (read the
issue for the full list ;-)). |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年01月30日 13:14:21 | vstinner | set | recipients:
+ vstinner, loewis, rhettinger, jcea, mark.dickinson, belopolsky, lars.gustaebel, larry, nadeem.vawda, Arfrever, r.david.murray, skrah, Alexander.Belopolsky, rosslagerwall, khenriksson, ericography |
| 2012年01月30日 13:14:20 | vstinner | link | issue11457 messages |
| 2012年01月30日 13:14:20 | vstinner | create |
|