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-11.17:17:01
SpamBayes Score 1.4164605e-06
Marked as misclassified No
Message-id <4E6CED0B.2030304@v.loewis.de>
In-reply-to <1315752603.64.0.416678411165.issue11457@psf.upfronthosting.co.za>
Content
> The quad-precision float would be highly portable

Larry, please stop this discussion in this issue. I believe
a PEP would be needed, and would likely be rejected because
of the very very very long list of issues that can't be
resolved. I think you seriously underestimate the problems.
Please trust Mark on this.

For example, gcc doesn't support __float128 in 32-bit mode
on x86.

> If float128 isn't viable then the best remaining option is Decimal.
> But changing st_mtime to Decimal would be an even more violent change
> than changing it to float was.  I propose adding the Decimal fields
> "ctime", "atime", and "mtime" to the named tuple returned by
> os.stat().

That sounds reasonable to me. While we are at it, I'd rename
"ctime" to "creationtime" on Windows, to prevent people from
believing it is "ctime" (i.e. inode change time).
History
Date User Action Args
2011-09-11 17:17:02loewissetrecipients: + loewis, jcea, mark.dickinson, belopolsky, lars.gustaebel, vstinner, larry, nadeem.vawda, Arfrever, r.david.murray, skrah, Alexander.Belopolsky, rosslagerwall, khenriksson
2011-09-11 17:17:01loewislinkissue11457 messages
2011-09-11 17:17:01loewiscreate