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

vadmium+py at gmail.com vadmium+py at gmail.com
Sun Jan 22 00:22:58 EST 2017

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

Doc/reference/expressions.rst:1154: 8-bit strings are fully
interoperable in this behavior. [#]_
On 2017/01/21 13:03:53, storchaka wrote:
> This description is misleading. Unicode and 8-bit strings are not
> interoperable.
> >>> chr(0xff) == unichr(0xff)
> __main__:1: UnicodeWarning: Unicode equal comparison failed to convert
> arguments to Unicode - interpreting them as being unequal
> False
> >>> chr(0xff) < unichr(0xff)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position
0: ordinal
> not in range(128)
> When compare str and unicode, the str operand is converted to Unicode.
If the
> conversion is failed, values are traited as non-equal.

Okay, I shall replace the second sentence with:

When comparing an 8-bit string and a Unicode string, the 8-bit string is
converted to Unicode. If the conversion fails, the strings are
considered unequal.

Doc/reference/expressions.rst:1174: - For two collections to compare
equal, they must be of the same type, have
On 2017/01/21 13:03:53, storchaka wrote:
> Subclasses are comparable with base class or other subclasses of the
same base
> class.

This would apply equally to the Python 3 version.

Andy originally omitted the “built-in” clarifier, and wrote “(or
subtypes of each other)”. But then he wanted to make this specific to
only built-in types, not user-defined subclasses:


IMO much of the finer details would be better off separately with the
documentation for each type, e.g. in Doc/library/stdtypes.rst. We should
keep the documentation on expressions general. A bit like how the
documentation on function call expressions just points to a different
chapter for the behaviour of each built-in function.

Doc/reference/expressions.rst:1197: User-defined classes that customize
their comparison behavior should follow
On 2017/01/21 13:03:53, storchaka wrote:
> Would it be worth to document when custom comparison methods should
> NotImplemented?

Perhaps. See <https://bugs.python.org/issue15997>. Some of the details
are already in datamodel.rst under __eq__() etc, but they may make more
sense here under the comparison operators.

For the time being, do you think the link to :meth:`__lt__` in the third
paragraph is enough of a hint?

> The hash of hashable user defined classes should be consistent with
> equality.

Agreed. I shall include a bullet point like

* The :func:`hash` result should be consistent with equality. Objects
that are equal should either have the same hash value, or be marked as

This also applies to Python 3.


More information about the docs mailing list