Some small edits, e.g. finite -> sized.

pep-3119.txt

@@ -153,6 +153,11 @@ in the subclass (using ``super`` or direct invocation).  For example::
 
     C()  # works
 
+**Note:** The ``@abstractmethod`` decorator should only be used inside
+a class body.  Dynamically adding abstract methods to a class, or
+attempting to modify the abstraction status of a method or class once
+it is created, are not supported.
+
 **Implementation:** The ``@abstractmethod`` decorator sets the
 function attribute ``__isabstractmethod__`` to the value ``True``.
 The ``type.__new__`` method computes the type attribute
@@ -306,13 +311,13 @@ These abstract classes represent various stages of "set-ness".  The
 most fundamental set operation is the membership test, written as ``x
 in s`` and implemented by ``s.__contains__(x)``.  This is already
 taken care of by the `Container`` class defined above.  Therefore, we
-define a set as finite, iterable container for which certain
+define a set as a sized, iterable container for which certain
 invariants from mathematical set theory hold.
 
 The built-in type ``set`` derives from ``MutableSet``.  The built-in
 type ``frozenset`` derives from ``HashableSet``.
 
-You might wonder why we require a set to be finite -- surely certain
+You might wonder why we require a set to be sized -- surely certain
 infinite sets can be represented just fine in Python.  For example,
 the set of even integers could be defined like this::
 
@@ -326,7 +331,7 @@ general without using a symbolic algebra package.  So I consider this
 out of the scope of a pragmatic proposal like this.
 
 ``Set``
-    This is a finite, iterable, partially ordered container, i.e. a
+    This is a sized, iterable, partially ordered container, i.e. a
     subclass of ``Sized``, ``Iterable``, ``Container`` and
     ``PartiallyOrdered``.  Not every subset of those three classes is
     a set though!  Sets have the additional invariant that each
@@ -379,9 +384,9 @@ out of the scope of a pragmatic proposal like this.
     as dictionary keys.  (A similar constraint exists on the hash
     values for different types of numbers and strings.)
 
-    **Open issues:** Should I spell out the hash algorithm?  Should
-    there be another ABC that derives from Set and Hashable (but not
-    from Composable)?
+    **Open issues:** Spell out the hash algorithm.  Should there be
+    another ABC that derives from Set and Hashable (but not from
+    Composable)?
 
 ``MutableSet``
     This is a subclass of ``ComposableSet`` implementing additional
@@ -406,7 +411,9 @@ out of the scope of a pragmatic proposal like this.
         Abstract method that empties the set.  The abstract
         implementation raises ``NotImplementedError``.  (Making this
         concrete would just add a slow, cumbersome default
-        implementation.)
+        implementation.)  **Open issues:** Forcing every mutable set
+        to implement this may be a pain for such a fairly
+        non-essential method.  Perhaps just drop it?
 
     ``.pop()``
         Concrete method that removes an arbitrary item.  If the set is
@@ -421,8 +428,10 @@ out of the scope of a pragmatic proposal like this.
 
     This also supports the in-place mutating operations ``|=``,
     ``&=``, ``^=``, ``-=``.  These are concrete methods whose right
-    operand can be an arbitrary ``Iterable``.  It does not support the
-    named methods that perform (almost) the same operations.
+    operand can be an arbitrary ``Iterable``, except for ``&=``, whose
+    right operand must be a ``Container``.  This ABC does not support
+    the named methods present on the built-in concrete ``set`` type
+    that perform (almost) the same operations.
 
 
 Mappings
@@ -536,7 +545,9 @@ Strings
 
 Python 3000 has two built-in string types: byte strings (``bytes``),
 deriving from ``MutableSequence``, and (Unicode) character strings
-(``str``), deriving from ``HashableSequence``.
+(``str``), deriving from ``HashableSequence``.  They also derive from
+``TotallyOrdered``.  If we were to introduce ``Searchable``, they
+would also derive from that.
 
 **Open issues:** define the base interfaces for these so alternative
 implementations and subclasses know what they are in for.  This may be
@@ -544,8 +555,8 @@ the subject of a new PEP or PEPs (PEP 358 should be co-opted for the
 ``bytes`` type).
 
 
-ABCs for Numbers
-----------------
+Numbers
+-------
 
 ABCs for numerical types are defined in PEP 3141.