Added a note in each regarding the fact that unicode strings that look the same

may not compare equal (due to the possibility of multiple representations).

1 files changed, 7 insertions, 1 deletions

diff --git a/Doc/reference/expressions.rst b/Doc/reference/expressions.rst
index 3364fd6..a1c4185 100644
--- a/Doc/reference/expressions.rst
+++ b/Doc/reference/expressions.rst
@@ -1040,7 +1040,7 @@ Comparison of objects of the same type depends on the type:
 
 * Strings are compared lexicographically using the numeric equivalents (the
   result of the built-in function :func:`ord`) of their characters.  Unicode and
-  8-bit strings are fully interoperable in this behavior.
+  8-bit strings are fully interoperable in this behavior. [#]_
 
 * Tuples and lists are compared lexicographically using comparison of
   corresponding elements.  This means that to compare equal, each element must
@@ -1328,6 +1328,12 @@ groups from right to left).
    cases, Python returns the latter result, in order to preserve that
    ``divmod(x,y)[0] * y + x % y`` be very close to ``x``.
 
+.. [#] While comparisons between unicode strings make sense at the byte
+   level, they may be counter-intuitive to users. For example, the
+   strings ``u"\u00C7"`` and ``u"\u0327\u0043"`` compare differently,
+   even though they both represent the same unicode character (LATIN
+   CAPTITAL LETTER C WITH CEDILLA).
+
 .. [#] The implementation computes this efficiently, without constructing lists or
    sorting.