Author Alexander.Belopolsky
Recipients Alexander.Belopolsky, Arfrever, belopolsky, jcea, khenriksson, larry, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rosslagerwall, skrah, vstinner
Date 2011-09-09.21:22:37
SpamBayes Score 6.77663e-06
Marked as misclassified No
Message-id <CAP7h-xaBOV=FZBk67h89y8_c8RUDrojtAQ78jT=NOHhNuGL_GQ@mail.gmail.com>
In-reply-to <1315601453.24.0.856996725809.issue11457@psf.upfronthosting.co.za>
Content
On Fri, Sep 9, 2011 at 4:50 PM, Larry Hastings <report@bugs.python.org> wrote:
..
> I think a pair of integers is a poor API.  It ties the value of the fractional part to nanoseconds.  What happens
> when a future filesystem implements picosecond resolution?

If history repeats, struct stat will grow new st_xtimesuperspec
fields, st_xtimespec will become a macro expanding to
st_xtimesuperspec.tv_picosec and we will get a request to support that
in os.stat().  I don't see why this conflicts with
stat_result.st_xtimespec returning a (sec, nsec) tuple.  If we will
ever have to support higher resolution,  stat_result will grow another
member with a (sec, picosec) or whatever will be appropriate value.

>  And then later goes to femtoseconds?

Same thing.

>  Or some platform chooses another divisor (2**32)?

Unlikely, but C API will dictate Python API if this happens.
History
Date User Action Args
2011-09-09 21:22:41Alexander.Belopolskysetrecipients: + Alexander.Belopolsky, loewis, jcea, mark.dickinson, belopolsky, lars.gustaebel, vstinner, larry, nadeem.vawda, Arfrever, r.david.murray, skrah, rosslagerwall, khenriksson
2011-09-09 21:22:38Alexander.Belopolskylinkissue11457 messages
2011-09-09 21:22:37Alexander.Belopolskycreate