diff -r e481e6e04863 -r 8438ee5eef8b Doc/reference/expressions.rst
--- a/Doc/reference/expressions.rst	Mon Oct 13 09:05:08 2014 +0200
+++ b/Doc/reference/expressions.rst	Mon Oct 13 10:56:12 2014 +0200
@@ -1081,7 +1081,7 @@
 an attempt raises :exc:`TypeError`.  A motivation for this default behavior is
 the lack of a similar invariant as for equality.
 
-The behavior of the default equality comparison that instances with different
+The behavior of the default equality comparison, that instances with different
 identities are always unequal, may be in contrast to what types will need that
 have a sensible definition of object value and value-based equality.  Such types
 will need to customize their comparison behavior, and in fact, a number of
@@ -1089,7 +1089,7 @@
 
 The following list describes the comparison behavior of the most important
 built-in types.  Unless otherwise stated, two instances of built-in types can
-only be compared if they are of the same type (or subtypes of each other);
+only be compared if they are of the same type or one is a subtype of the other;
 otherwise, :exc:`TypeError` is raised:
 
 * Numbers of built-in numeric types (:ref:`typesnumeric`) and of the standard
@@ -1114,7 +1114,7 @@
   numerical Unicode code points (the result of the built-in function
   :func:`ord`) of their characters. [#]_
 
-  Strings cannot directly be compared with binary sequences, and vice versa!
+  Strings and binary sequences cannot be directly compared.
 
 * Sequences (instances of :class:`tuple`, :class:`list`, or :class:`range`) are
   compared lexicographically using comparison of corresponding elements.
@@ -1141,22 +1141,20 @@
     >>> [nan] == [nan]
     True                  <-- list enforces reflexivity and tests identity first
 
-  Lexicographical comparison between collections works as follows:  For two
-  collections to compare equal, they must be of the same type (or subtypes of
-  each other), have the same length, and each pair of corresponding elements
+  Lexicographical comparison between built-in collections works as follows:  For two
+  collections to compare equal, they must be of the same type,
+  have the same length, and each pair of corresponding elements
   must compare equal.
   Collections that support order comparison are ordered the same as their first
   unequal elements (for example, ``[1,2,x] <= [1,2,y]`` has the same value as
   ``x <= y``).  If a corresponding element does not exist, the shorter
   collection is ordered first (for example, ``[1,2] < [1,2,3]`` is true).
 
-* Mappings (instances of :class:`dict`) are compared lexicographically using
-  comparison of corresponding elements.  Corresponding elements are those whose
-  keys compare equal.
-
-  Mappings do not support order comparison.
-
-  Equality comparison of mappings enforces reflexivity of its keys and elements.
+* Mappings (instances of :class:`dict`) compare equal if and only if they have
+  equal `(key, value)` pairs. Equality comparison of the keys and elements
+  enforces reflexivity.
+  
+  Order comparisons (``<``, ``>``, ``<=``, and ``>=``) raise :exc:`TypeError`.
 
 * Sets (instances of :class:`set` or :class:`frozenset`) can be compared within
   the same type and between different of those types.
@@ -1210,7 +1208,7 @@
     ``x > y`` and ``not x <= y`` (for total ordering)
 
   The last two expressions apply to totally ordered collections (e.g. to
-  sequences and mappings, but not to sets). See also the
+  sequences, but not to sets or mappings). See also the
   :func:`~functools.total_ordering` decorator.
   
 Python does not enforce these consistency rules. In fact, the not-a-number
@@ -1501,9 +1499,9 @@
 
 .. [#] The Unicode standard distinguishes between :dfn:`code points`
    (e.g. U+0041) and :dfn:`abstract characters` (e.g. "LATIN CAPITAL LETTER A").
-   While most abstract characters in Unicode are represented using exactly one
-   code point, there is a number of abstract characters that can be represented
-   using more than one code point or sequence of code points.  For example, the
+   While most abstract characters in Unicode are only represented using one
+   code point, there is a number of abstract characters that can in addition be
+   represented using a sequence of more than one code point.  For example, the
    abstract character "LATIN CAPITAL LETTER C WITH CEDILLA" can be represented
    as a single :dfn:`precomposed character` at code position U+00C7, or as a
    sequence of a :dfn:`base character` at code position U+0043 (LATIN CAPITAL