Message143802
| 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.7766264e-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:41 | Alexander.Belopolsky | set | recipients:
+ 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:38 | Alexander.Belopolsky | link | issue11457 messages |
| 2011年09月09日 21:22:37 | Alexander.Belopolsky | create |
|