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 Arfrever, belopolsky, jcea, khenriksson, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rosslagerwall
Date 2011-06-03.19:57:51
SpamBayes Score 3.1651507e-06
Marked as misclassified No
Message-id <1307131071.91.0.794356823268.issue11457@psf.upfronthosting.co.za>
In-reply-to
Content
I suggest that rather than using composite time stamps, decimal.Decimal is used to represent high-precision time in Python.

On input to os.utime, the function could just polymorphically accept Decimal, and try its best.

I see three approaches that preserve compatibility for stat (plus the incompatible one of just changing the field types of struct stat):
1. have a flag in the stat module to change the field types globally.
   This would be appropriate if the ultimate goal is to eventually change
   the fields in an incompatible way in Python 4.
2. have a flag to stat that changes the field types, on a per-call basis
3. mirror the existing fields, into _decimal versions.
History
Date User Action Args
2011-06-03 19:57:52loewissetrecipients: + loewis, jcea, mark.dickinson, belopolsky, lars.gustaebel, nadeem.vawda, Arfrever, r.david.murray, rosslagerwall, khenriksson
2011-06-03 19:57:51loewissetmessageid: <1307131071.91.0.794356823268.issue11457@psf.upfronthosting.co.za>
2011-06-03 19:57:51loewislinkissue11457 messages
2011-06-03 19:57:51loewiscreate