[Python-Dev] Decimal <-> float comparisons in py3k. (original) (raw)
Mark Dickinson dickinsm at gmail.com
Wed Mar 17 16:04:10 CET 2010
- Previous message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Next message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Mar 16, 2010 at 5:15 PM, Guido van Rossum <guido at python.org> wrote:
Definitely some. Stricter comparison rules are a frequent cause of problems when code is first ported to 3.x. While you'd think that code comparing a float and a Decimal is already broken, there's a surprising number of situations where that's not necessary the case, e.g. when an arbitrary but stable ordering is needed.
Hmm. Okay. It seems like backporting the exception isn't a real option, then.
A nitpick: the current 2.x behaviour fails to give an arbitrary but stable ordering; it merely gives an arbitrary ordering:
sorted([Decimal(1), 2, 3.0]) [Decimal('1'), 2, 3.0] sorted([2, Decimal(1), 3.0]) [3.0, Decimal('1'), 2]
So long as your list contains only floats and Decimals you're fine, but for a list containing floats, integers and Decimals the ordering is no longer stable: the problem, of course, being that int <-> float and int <-> Decimal comparisons use a rule (compare by numeric value) that's not compatible with the way that floats and Decimals are compared. This seems like yet another possible cause of subtle bugs, and again would be fixed by the proposed change in behaviour. On the other hand, I've not seen any reports of anyone encountering this in real life.
Mark
Mark
- Previous message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Next message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]