Author mark.dickinson
Recipients mark.dickinson, pitrou, skrah, steven.daprano
Date 2012-08-04.17:45:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1344102329.03.0.136141685812.issue15544@psf.upfronthosting.co.za>
In-reply-to
Content
> Why not add a is_nan() method to float numbers instead?

That could work.  The duplication of float.is_nan and math.isnan (not to mention the different spellings) would be a bit ugly, but perhaps worth it.  It would make sense to add float.is_infinite and (possibly) float.is_finite methods at the same time.

Looks like we've got two separate issues here, that should probably be split into two separate bug reports.  The first issue is that Decimal.__float__ is brain-dead when it comes to NaNs with payloads;  I consider that a clear bug, and Steven's patch fixes it nicely for the Python version of decimal.  The second has to do with finding a nice type-agnostic way of determing whether something is a NaN---anyone mind if I open a separate issue for this?

W.r.t. the first issue:  Steven, thanks for the patch;  looks fine to me at first glance.

Two questions:  (1) What would you think about raising ValueError explicitly for the signaling NaN case rather than falling back to the ValueError coming from the string-to-float conversion.  I think the intentions of the code would be a little clearer that way;  and we get to choose a more informative error message that way, too.  (2) Should we apply the fix to 2.7 and/or 3.2 as well?

I'll look at extending Steven's fix to the cdecimal code, unless Stefan really wants to do it (which would be fine with me :-).
History
Date User Action Args
2012-08-04 17:45:29mark.dickinsonsetrecipients: + mark.dickinson, pitrou, steven.daprano, skrah
2012-08-04 17:45:29mark.dickinsonsetmessageid: <1344102329.03.0.136141685812.issue15544@psf.upfronthosting.co.za>
2012-08-04 17:45:28mark.dickinsonlinkissue15544 messages
2012-08-04 17:45:27mark.dickinsoncreate