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 larry
Recipients Arfrever, belopolsky, jcea, khenriksson, larry, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rosslagerwall, skrah, vstinner
Date 2011-09-05.22:35:21
SpamBayes Score 4.4669655e-08
Marked as misclassified No
Message-id <1315262122.72.0.75646294415.issue11457@psf.upfronthosting.co.za>
In-reply-to
Content
This is probably a terrible idea, but: what about using a subclass of float that internally preserves the original sec / usec values?  Call it a utime_float for now.  os.stat would produce them, and os.utime would look for them--and if it found one it'd pull out the precise numbers.

Type promotion as a result of binary operators:
  utime_float OP int   = utime_float
  utime_float OP float = degrades to float

I suspect code rarely does math on atime/utime/ctime and then writes out the result.  Most of the time they simply propogate the utime values around, comparing them to each other, or setting them unchanged.

For those rare occasions when someone wants to change the fractional part of a utime_float, we could provide a function utime_fractional(int) -> utime_float.

Advantages:
 * Nobody has to change any Python code.  In almost all circumstances they
   get complete accuracy for free.

Disadvantages:
 * Complicated.
 * Is a yucky hack.
 * Is a terrible idea.  (Now I'm sure of it!)
History
Date User Action Args
2011-09-05 22:35:22larrysetrecipients: + larry, loewis, jcea, mark.dickinson, belopolsky, lars.gustaebel, vstinner, nadeem.vawda, Arfrever, r.david.murray, skrah, rosslagerwall, khenriksson
2011-09-05 22:35:22larrysetmessageid: <1315262122.72.0.75646294415.issue11457@psf.upfronthosting.co.za>
2011-09-05 22:35:22larrylinkissue11457 messages
2011-09-05 22:35:21larrycreate