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

andreas.r.maier at gmx.de andreas.r.maier at gmx.de
Mon Oct 13 11:09:12 CEST 2014

File Doc/reference/expressions.rst (right):

Doc/reference/expressions.rst:1087: The behavior of the default equality
comparison that instances with different
On 2014/08/27 07:56:54, vadmium wrote:
> Needs a comma between “comparison, that”


Doc/reference/expressions.rst:1096: otherwise, :exc:`TypeError` is
> Everything is an instance of the built-in type “object”, and “subtypes
of each
> other” does not make much sense to me.

I plan to change that in the next version of the patch to "if they are
of the same type or one is a subtype of the other".
> I think the cases where TypeError is
> raised or not by default are already described above. Would it hurt to
just drop
> the second sentence?

Where do you see that it is stated above ? At the begin of the chapter,
it is stated that types do not need to be the same to be compared, which
is the general statement that is then refined by the sentence you
commented on, for built-in types. So I'd like to keep the second

Doc/reference/expressions.rst:1120: Strings cannot directly be compared
with binary sequences, and vice versa!
> I think the "be" is misplaced in this sentence (it should be "cannot
be directly
> compared").
My german English ... sorry for that...

> Further, the "and" conjunction seemed so jarring to me I wasn't sure
it was even
> grammatical (though after further consideration I understand it now).
> suggest dropping the whole "vice versa" clause, since the ability to
be compared
> is symmetric (even if the comparisons themselves are not). It wouldn't
> sense to say that A can be compared to B if B cannot be compared to A.
I agree.
Just to explain myself: My original motivation was driven by the fact
that the rich comparison methods are all unsymmetrical (they are defined
on the left hand operand and turning the comparison expression around
invokes the other method if both have one, which might be implemented
inconsistently. Now, because strings and sequences are both built-in
types, we know what their implementations do, and so using a language
that is based on the theoretical capability that it could have been
different, is just adding complexity.

> And finally, the exclamation mark at the end is a bit overemphatic!!1!

> tldr, make this sentence: "Strings and binary sequences cannot be
> compared."

Doc/reference/expressions.rst:1149: each other), have the same length,
and each pair of corresponding elements
> Again, “subtypes of each other” does not make sense. Maybe just say
you cannot
> compare between lists, tuples, and ranges [and byte sequences and text
> this way. [I understand comparing the different kinds of byte
sequences is meant
> to work though.]
I had the sentence about subtypes only to cover the case of user-defined
collections derived from the built-in collections. However, because this
section is about the behavior of built-in collections, that scope should
be maintained consistently. And because all built-in collections inherit
directly from object, the case of subtypes between them does not exist.
I have removed the phrase "or subtypes of each other)".

One point still to clarify, though: Which different types of byte
sequences can be compared in Py 3.4?

Doc/reference/expressions.rst:1156: * Mappings (instances of
:class:`dict`) are compared lexicographically using
On 2014/08/27 07:56:54, vadmium wrote:
> Not sure “lexicographical comparison” makes sense unless the items
have an
> order. Maybe the original wording was better?
The original text said "same (key, value) pairs" without pointing out
that that does not mean "same object", plus it did not point out that
reflexivity is enforced on both key and value. I'll come up with
something that addresses your comment and still clarifies that.

Doc/reference/expressions.rst:1216: sequences and mappings, but not to
sets). See also the
> Perhaps drop “mappings”; even OrderedDict does not do ordering
comparisons for
> me
Agreed, we explicitly state that 'dict' mappings do not support


More information about the docs mailing list