Message143873
| 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:02 | loewis | set | recipients:
+ 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:01 | loewis | link | issue11457 messages |
| 2011年09月11日 17:17:01 | loewis | create |
|