Martin v. Löwis <mar...@v.loewis.de> added the comment: > As I wrote before, I would prefer to keep the same number of fields > in the Python structure and in the C structure, but I don't have a > strong opinion on this choice.
I'm with Larry - exposing time fields as structured records is hostile to the programmer. It is a true pain in C to do any meaningful computation on timeval or timespec values. It may be a little more convenient in Python, but we should really attempt to expose the time stamps as single fields that support arithmetics and string conversion, else people will hate us for 500 years (or when we next need to revise this struct). Nothing is *gained* by exposing structured time. People may see it as an advantage that this closely matches the POSIX spec, but all it does in reality is to confront people with platform differences for no true gain. > s = os.stat(filename, nanoseconds=True) sec, nsec = s.ctime ctime = > sec + nsec * 1e-9 > > What should be done if the OS only has a resolution of 1 sec? Raise > an exception, or use nsec=0? Same question if we add *_nsec fields: > these fields are optional, or always present? If we declare that stat_result has nanosecond resolution, then it should have that even on systems that only support second resolution (or 2-second resolution, like FAT). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11457> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com