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.56553e-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:21vstinnersetrecipients: + 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:20vstinnerlinkissue11457 messages
2012-01-30 13:14:20vstinnercreate