[issue6431] Fraction fails equality test with a user-defined type

New submission from Case Van Horsen : I've ported the GMPY module to Python 3 and found a problem comparing Fraction to gmpy.mpq. mpq is the rational type in gmpy and knows how to convert a Fraction into an mpq. All operations appear to work properly except "Fraction == mpq". "mpq == Fraction" d

[issue6431] Fraction fails equality test with a user-defined type

Mark Dickinson added the comment: I agree this should be fixed. The conversion to float in the else clause seems wrong to me: it can lose precision, making two unequal values compare equal. I also agree that we should be getting NotImplemented here. Do you have a patch available? As an as

[issue6431] Fraction fails equality test with a user-defined type

Changes by Mark Dickinson : -- stage: -> needs patch versions: +Python 2.6, Python 2.7, Python 3.2 ___ Python tracker ___ ___ Python-b

[issue6431] Fraction fails equality test with a user-defined type

Case Van Horsen added the comment: On Tue, Jul 7, 2009 at 1:26 AM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > I agree this should be fixed.  The conversion to float in the else > clause seems wrong to me: it can lose precision, making two unequal > values compare equal.  I

[issue6431] Fraction fails equality test with a user-defined type

Case Van Horsen added the comment: Change Fraction __eq__ method to give the other operand a chance to perform the comparison if Fraction doesn't understand the other operand. -- keywords: +patch Added file: http://bugs.python.org/file14470/fractions_patch.diff

[issue6431] Fraction fails equality test with a user-defined type

Mark Dickinson added the comment: Thanks. Could you provide some tests? (If you don't have time then that's fine: I'll probably get to this eventually, but it might take a while...) -- assignee: -> marketdickinson priority: -> normal stage: needs patch -> test needed

[issue6431] Fraction fails equality test with a user-defined type

Mark Dickinson added the comment: A good solution should ensure that all 6 comparison operators behave in the same way for the same input types: that is, if x == y returns NotImplemented for some particular Python objects x and y, then x < y, x <= y, etc. should also return NotImplemented, a

[issue6431] Fraction fails equality test with a user-defined type

Case Van Horsen added the comment: I've attached a patch that creates DummyRational and then tests comparisons between Fraction and DummyRational. The __eq__ method also verifies that the type of the other argument is fractions.Fraction. -- Added file: http://bugs.python.org/file14504/p

[issue6431] Fraction fails equality test with a user-defined type

Mark Dickinson added the comment: Thanks again, casevh! The patch looks good. I've added to it a bit, though---see issue6431.patch. In detail: - don't use subtraction with unknown types for <, <=, >, >=; this is dangerous, since the unknown type may well do a lossy conversion, and compa

[issue6431] Fraction fails equality test with a user-defined type

Jeffrey Yasskin added the comment: The fallback behavior in Fraction was meant to demonstrate the suggested fallback behavior for user-defined types. In particular, the idea was that all Reals would (by default) be comparable to each other, even if they didn't know about each other. Unfortuna

[issue6431] Fraction fails equality test with a user-defined type

Mark Dickinson added the comment: [Jeffrey] > In particular, the idea was that all Reals would (by default) be > comparable to each other, even if they didn't know about each other. Understood, but I don't think this is an attainable goal. I don't see any reasonable way to make it happen with

[issue6431] Fraction fails equality test with a user-defined type

Jeffrey Yasskin added the comment: If you think it's better, I'm happy to make the other tradeoff. -- ___ Python tracker ___ ___ Pytho

[issue6431] Fraction fails equality test with a user-defined type

Case Van Horsen added the comment: On Thu, Jul 16, 2009 at 11:34 AM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > Thanks again, casevh!  The patch looks good.  I've added to it a bit, > though---see issue6431.patch.  In detail: > > - don't use subtraction with unknown types f

[issue6431] Fraction fails equality test with a user-defined type

Mark Dickinson added the comment: Applied in r74078 (py3k), r74079 (release31-maint). I'll backport to 2.x. -- ___ Python tracker ___ ___

[issue6431] Fraction fails equality test with a user-defined type

Mark Dickinson added the comment: Backported to trunk in r74080. I don't think it's worth fixing this in 2.6: it seems unlikely that the changed comparison behaviour would cause breakage, but I don't want to take the chance. Thanks Case for the report and patches! -- resolution: -