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 terry.reedy
Recipients docs@python, rhettinger, terry.reedy
Date 2011-05-12.21:59:32
SpamBayes Score 1.4464746e-10
Marked as misclassified No
Message-id <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
In-reply-to
Content
Current 3.2 doc, 5.9. Comparisons, has this paragraph about mixed-type comparisons.

"The operators <, >, ==, >=, <=, and != compare the values of two objects. The objects need not have the same type. If both are numbers, they are converted to a common type. Otherwise, the == and != operators *always* consider objects of different types to be unequal, while the <, >, >= and <= operators raise a TypeError when comparing objects of different types that do not implement these operators for the given pair of types. You can control comparison behavior of objects of non-built-in types by defining rich comparison methods like __gt__(), described in section Basic customization."

Sentence 3: "If both are numbers, they are converted to a common type." I suspect it would be more true to say 'common internal type' as I would not think it a language requirement to produce Python objects.

In any case, I think it is only true for built-in number types, and I do not see that qualification anywhere previously.

That aside, it does not appear to be true for Decimals and Fractions in 2.7.1.

Sentence 4: first clause is only true for built-in types. That qualification is not obvious to everyone, as evidenced by a current python-list sub thread.

For 2.7, which has a different continuation, I suggest adding 'built-in' before 'objects of'.
For 3.2/3, I suggest deleting '*always*' and adding a comma after 'TypeError' so that the 'when' condition applies to equality comparisons also.

After discussion about same-type comparisons, there is another paragraph about mixed-type comparison:

"Comparison of objects of the differing types depends on whether either of the types provide explicit support for the comparison. Most numeric types can be compared with one another, but comparisons of float and Decimal are not supported to avoid the inevitable confusion arising from representation issues such as float('1.1') being inexactly represented and therefore not exactly equal to Decimal('1.1') which is. When cross-type comparison is not supported, the comparison method returns NotImplemented. This can create the illusion of non-transitivity between supported cross-type comparisons and unsupported comparisons. For example, Decimal(2) == 2 and 2 == float(2) but Decimal(2) != float(2)."

I suggest deleting this entirely. The first sentence and first clause of the second repeat what was said above. The rest is obsolete as float/decimal comparisons *are* implemented in 2.7.1 and 3.2.0.
History
Date User Action Args
2011-05-12 21:59:34terry.reedysetrecipients: + terry.reedy, rhettinger, docs@python
2011-05-12 21:59:33terry.reedysetmessageid: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
2011-05-12 21:59:33terry.reedylinkissue12067 messages
2011-05-12 21:59:32terry.reedycreate