[Python-Dev] Decimal <-> float comparisons in py3k. (original) (raw)
Terry Reedy tjreedy at udel.edu
Fri Mar 19 01:27:25 CET 2010
- Previous message: [Python-Dev] Decimal & lt; -& gt; float comparisons in py3k.
- Next message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3/18/2010 5:48 PM, Nick Coghlan wrote:
Mark Dickinson wrote:
Could everyone live with making float<->Decimal comparisons raise an exception in 2.7? I could, with the caveat that if this causes problems for real world code, then changing it to produce the correct answer (as per your patch) should be applied as a bug fix in both 2.7 and 3.2. Note that even in Py3k there are some fairly serious weirdnesses kicking around due to the intransitive nature of numeric equality though:
from decimal import Decimal as dec set((1, 1.0, dec("1.0"))) {1} set((1.0, dec("1.0"))) {1.0, Decimal('1.0')} d = {} from decimal import Decimal as dec d[1] = d[1.0] = d[dec("1.0")] = 42 d {1: 42} d[1.0] = d[dec("1.0")] = 42 d {1: 42} del d[1] d[1.0] = d[dec("1.0")] = 42 d {1.0: 42, Decimal('1.0'): 42} When there is a clear, correct way (based on Decimal.fromfloat) to make numeric comparison behave in accordance with the rules of mathematics, do we really want to preserve strange, unintuitive behaviour like the above?
I would still strongly prefer that equality intransitivity be fixed one way or another (I suggested two on the tracker). The many ways it makes sets misbehave was discussed in both of http://mail.python.org/pipermail/python-list/2008-September/508859.html http://bugs.python.org/issue4087
Terry Jan Reedy
- Previous message: [Python-Dev] Decimal & lt; -& gt; float comparisons in py3k.
- Next message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]