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 mark.dickinson
Recipients alexandre.vassalotti, amaury.forgeotdarc, christian.heimes, eric.smith, gvanrossum, jaredgrubb, mark.dickinson, nascheme, noam, preston, rhettinger, tim.peters
Date 2009-04-07.19:43:59
SpamBayes Score 1.8417894e-09
Marked as misclassified No
Message-id <1239133442.18.0.782126582673.issue1580@psf.upfronthosting.co.za>
In-reply-to
Content
> Historically, we've had a stronger requirement: if you print repr(x)
> and ship that string to a different machine, float() of that string
> returns the same value, assuming both systems use the same internal FP
> representation (e.g. IEEE).

Hmm.  With the py3k-short-float-repr stuff, we should be okay moving 
things between different CPython boxes, since float() would use Gay's code 
and so would be correctly rounded for any length input, not just input 
with 17 significant digits.

But for a CPython-generated short repr to give the correct value on some 
other implementation, that implementation would also have to have a 
correctly rounded string->float.

For safety's sake, I'll make sure that marshal (version 1) and pickle 
(protocol 0) are still outputting the full 17 digits.
History
Date User Action Args
2009-04-07 19:44:02mark.dickinsonsetrecipients: + mark.dickinson, gvanrossum, tim.peters, nascheme, rhettinger, amaury.forgeotdarc, eric.smith, christian.heimes, alexandre.vassalotti, noam, jaredgrubb, preston
2009-04-07 19:44:02mark.dickinsonsetmessageid: <1239133442.18.0.782126582673.issue1580@psf.upfronthosting.co.za>
2009-04-07 19:44:00mark.dickinsonlinkissue1580 messages
2009-04-07 19:43:59mark.dickinsoncreate