[docs] Doc: remove errors about mixed-type comparisons. (issue 12067)

[vadmium+py at gmail.com]

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py
File Lib/test/test_compare.py (right):

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode328
Lib/test/test_compare.py:328: def assert_insts(self, i1, i2, equal,
comp, i1_meth=(), i2_meth=()):
On 2015/03/02 18:56:14, andymaier wrote:
> Will change name to assert_comparisons, for now. I will split up the
two
> _subtest methods into six, for better identification based on
subTest() (I
> really like that), but if I look at the number of calls to
assert_comparisons(),
> I don't think I'd like to duplicate them.

Fair enough. Though I think only one of those functions would need to be
called at a time, depending on whether comp was None or not. So
assert_equality_only() would check for TypeError, and
assert_total_order() would try all six comparisons. I don’t think there
would be duplicate calls.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode569
Lib/test/test_compare.py:569: self.assert_insts(c1, c1, True,   0,
Class_str.meth, Class_str.meth)
On 2015/03/02 18:56:15, andymaier wrote:
> On the empty tuple meths: I wanted to have one place that has the
knowledge that
> there are no meths, instead of repeating that in every invocation of
> assert_insts().
> 
> But I'm ok either way. Let me know which way you would recommend to
go.

Since you have now expanded the doc string for assert_comparisons() to
say the meths tuples are only needed for custom classes, I think it
would be consistent to remove them here.

https://bugs.python.org/review/12067/diff/14061/Lib/test/test_compare.py
File Lib/test/test_compare.py (right):

https://bugs.python.org/review/12067/diff/14061/Lib/test/test_compare.py#newcode343
Lib/test/test_compare.py:343: comp:       Integer indicating the
expected order comparison result:
Maybe:

“Integer indicating the expected order comparison result. Requires i1
and i2 to be totally ordered, meaning that at least one comparison is
true.”

Either i1 <= i2 or i1 >= i2 being true essentially means the pair of
objects are totally ordered. E.g. considering i1={"a"} and i2={"b"},
there is no valid comp value (short of something exotic like NaN).

https://bugs.python.org/review/12067/diff/14061/Lib/test/test_compare.py#newcode366
Lib/test/test_compare.py:366: i1_meth = ()
I think the code was simpler before with the parameter i1_meth=()
default in the function definition

https://bugs.python.org/review/12067/diff/14061/Lib/test/test_compare.py#newcode609
Lib/test/test_compare.py:609: self.assertTrue(c2 is not c3, "Testcase
error: c2 is c3")
Could use assertIsNot() here, and in other places

https://bugs.python.org/review/12067/diff/14061/Lib/test/test_compare.py#newcode614
Lib/test/test_compare.py:614: self.assertTrue(s2 is s3, "Testcase error:
s2 is not s3")
assertIs()

https://bugs.python.org/review/12067/