Message214683
| Author |
mark.dickinson |
| Recipients |
Arfrever, BreamoreBoy, benjamin.peterson, georg.brandl, larry, loewis, mark.dickinson, pitrou, schwab, skrah, tim.peters |
| Date |
2014年03月24日.11:15:14 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1395659715.54.0.807951107641.issue20904@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> I guess they will get fixed over time, or declared unsupported. :-)
Yes, probably. I'd fully support a move to get rid of that legacy code in Python 3.5. That would definitely require a python-dev discussion, though (and possibly a PEP): up until now the policy has been that Python just works with whatever floating-point format the platform's C double provides, with no assumptions about IEEE 754, etc.
I think we've mostly fixed the issues on mainstream platforms (e.g., Sun and Intel compilers on x86). Probably the most troublesome remaining case is ARM / OABI, where I think we still don't have code to deal with the mixed-endian (more strictly, little-endian swapped words) format for C doubles. There are some online environments (Python via JavaScript, etc.) that also currently use the legacy code. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2014年03月24日 11:15:15 | mark.dickinson | set | recipients:
+ mark.dickinson, tim.peters, loewis, georg.brandl, pitrou, larry, benjamin.peterson, Arfrever, skrah, BreamoreBoy, schwab |
| 2014年03月24日 11:15:15 | mark.dickinson | set | messageid: <1395659715.54.0.807951107641.issue20904@psf.upfronthosting.co.za> |
| 2014年03月24日 11:15:15 | mark.dickinson | link | issue20904 messages |
| 2014年03月24日 11:15:14 | mark.dickinson | create |
|