This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients Alexander.Belopolsky, Arfrever, belopolsky, jcea, khenriksson, larry, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rosslagerwall, skrah, vstinner
Date 2011-09-12.06:08:25
SpamBayes Score 1.0934239e-06
Marked as misclassified No
Message-id <>
In-reply-to <>
> 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).
Date User Action Args
2011-09-12 06:08:26loewissetrecipients: + loewis, jcea, mark.dickinson, belopolsky, lars.gustaebel, vstinner, larry, nadeem.vawda, Arfrever, r.david.murray, skrah, Alexander.Belopolsky, rosslagerwall, khenriksson
2011-09-12 06:08:25loewislinkissue11457 messages
2011-09-12 06:08:25loewiscreate