[Python-checkins] r58361 - peps/trunk/pep-3106.txt peps/trunk/pep-3119.txt

[guido.van.rossum]

Author: guido.van.rossum
Date: Mon Oct  8 05:15:35 2007
New Revision: 58361

Modified:
   peps/trunk/pep-3106.txt
   peps/trunk/pep-3119.txt
Log:
Typos and clarifications detected by Mark Summerfield.


Modified: peps/trunk/pep-3106.txt
==============================================================================
--- peps/trunk/pep-3106.txt	(original)
+++ peps/trunk/pep-3106.txt	Mon Oct  8 05:15:35 2007
@@ -15,7 +15,7 @@
 
 This PEP proposes to change the .keys(), .values() and .items()
 methods of the built-in dict type to return a set-like or unordered
-container object whose contents are derived of the underlying
+container object whose contents are derived from the underlying
 dictionary rather than a list which is a copy of the keys, etc.; and
 to remove the .iterkeys(), .itervalues() and .iteritems() methods.
 
@@ -64,6 +64,7 @@
 
     a = d.items()
     for k, v in a: ...
+    # And later, again:
     for k, v in a: ...
 
 Effectively, iter(d.keys()) (etc.) in Python 3.0 will do what
@@ -72,8 +73,8 @@
 
 The objects returned by the .keys() and .items() methods behave like
 sets.  The object returned by the values() method behaves like a much
-simpler unordered collection; anything more would require too much
-implementation effort for the rare use case.
+simpler unordered collection -- it cannot be a set because duplicate
+values are possible.
 
 Because of the set behavior, it will be possible to check whether two
 dicts have the same keys by simply testing::
@@ -268,7 +269,7 @@
 __hash__(); their value can change if the underlying dict is mutated.
 
 The only requirements on the underlying dict are that it implements
-__getitem__(), __contains__(), __iter__(), and __len__(0.
+__getitem__(), __contains__(), __iter__(), and __len__().
 
 We don't implement .copy() -- the presence of a .copy()
 method suggests that the copy has the same type as the original, but

Modified: peps/trunk/pep-3119.txt
==============================================================================
--- peps/trunk/pep-3119.txt	(original)
+++ peps/trunk/pep-3119.txt	Mon Oct  8 05:15:35 2007
@@ -244,7 +244,7 @@
 ``__subclasscheck__`` and defines a ``register`` method.  The
 ``register`` method takes one argument, which much be a class; after
 the call ``B.register(C)``, the call ``issubclass(C, B)`` will return
-True, by virtue of of ``B.__subclasscheck__(C)`` returning True.
+True, by virtue of ``B.__subclasscheck__(C)`` returning True.
 Also, ``isinstance(x, B)`` is equivalent to ``issubclass(x.__class__,
 B) or issubclass(type(x), B)``.  (It is possible ``type(x)`` and
 ``x.__class__`` are not the same object, e.g. when x is a proxy
@@ -355,11 +355,12 @@
 (If this were implemented in CPython, an internal flag
 ``Py_TPFLAGS_ABSTRACT`` could be used to speed up this check [6]_.)
 
-**Discussion:** Unlike C++ or Java, abstract methods as defined here
-may have an implementation.  This implementation can be called via the
-``super`` mechanism from the class that overrides it.  This could be
-useful as an end-point for a super-call in framework using a
-cooperative multiple-inheritance [7]_, [8]_.
+**Discussion:** Unlike Java's abstract methods or C++'s pure abstract
+methods, abstract methods as defined here may have an implementation.
+This implementation can be called via the ``super`` mechanism from the
+class that overrides it.  This could be useful as an end-point for a
+super-call in framework using cooperative multiple-inheritance [7]_,
+[8]_.
 
 A second decorator, ``@abstractproperty``, is defined in order to
 define abstract data attributes.  Its implementation is a subclass of
@@ -387,9 +388,10 @@
             self.__x = value
         x = abstractproperty(getx, setx)
 
-A subclass inheriting an abstract property (declared using either the
-decorator syntax or the longer form) cannot be instantiated unless it
-overrides that abstract property with a concrete property.
+Similar to abstract methods, a subclass inheriting an abstract
+property (declared using either the decorator syntax or the longer
+form) cannot be instantiated unless it overrides that abstract
+property with a concrete property.
 
 
 ABCs for Containers and Iterators
@@ -447,8 +449,9 @@
     inefficient) implementation.  **Invariant:** If classes ``C1`` and
     ``C2`` both derive from ``Hashable``, the condition ``o1 == o2``
     must imply ``hash(o1) == hash(o2)`` for all instances ``o1`` of
-    ``C1`` and all instances ``o2`` of ``C2``.  IOW, two objects
-    should never compare equal but have different hash values.
+    ``C1`` and all instances ``o2`` of ``C2``.  In other words, two
+    objects should never compare equal if they have different hash
+    values.
 
     Another constraint is that hashable objects, once created, should
     never change their value (as compared by ``==``) or their hash
@@ -484,16 +487,16 @@
     method should return an ``Integer`` (see "Numbers" below) >= 0.
     The abstract ``__len__`` method returns 0.  **Invariant:** If a
     class ``C`` derives from ``Sized`` as well as from ``Iterable``,
-    the invariant ``sum(1 for x in o) == len(o)`` should hold for any
-    instance ``o`` of ``C``.
+    the invariant ``sum(1 for x in c) == len(c)`` should hold for any
+    instance ``c`` of ``C``.
 
 ``Container``
     The base class for classes defining ``__contains__``.  The
     ``__contains__`` method should return a ``bool``.  The abstract
     ``__contains__`` method returns ``False``.  **Invariant:** If a
     class ``C`` derives from ``Container`` as well as from
-    ``Iterable``, then ``(x in o for x in o)`` should be a generator
-    yielding only True values for any instance ``o`` of ``C``.
+    ``Iterable``, then ``(x in c for x in c)`` should be a generator
+    yielding only True values for any instance ``c`` of ``C``.
 
 **Open issues:** Conceivably, instead of using the ABCMeta metaclass,
 these classes could override ``__instancecheck__`` and
@@ -526,7 +529,7 @@
 These abstract classes represent read-only sets and mutable sets.  The
 most fundamental set operation is the membership test, written as ``x
 in s`` and implemented by ``s.__contains__(x)``.  This operation is
-already defined by the `Container`` class defined above.  Therefore,
+already defined by the ``Container`` class defined above.  Therefore,
 we define a set as a sized, iterable container for which certain
 invariants from mathematical set theory hold.
 
@@ -549,7 +552,7 @@
     The ordering operations have concrete implementations; subclasses
     may override these for speed but should maintain the semantics.
     Because ``Set`` derives from ``Sized``, ``__eq__`` may take a
-    shortcut and returns ``False`` immediately if two sets of unequal
+    shortcut and return ``False`` immediately if two sets of unequal
     length are compared.  Similarly, ``__le__`` may return ``False``
     immediately if the first set has more members than the second set.
     Note that set inclusion implements only a partial ordering;
@@ -622,7 +625,7 @@
     This also supports the in-place mutating operations ``|=``,
     ``&=``, ``^=``, ``-=``.  These are concrete methods whose right
     operand can be an arbitrary ``Iterable``, except for ``&=``, whose
-    right operand must be a ``Container``.  This ABC does not support
+    right operand must be a ``Container``.  This ABC does not provide
     the named methods present on the built-in concrete ``set`` type
     that perform (almost) the same operations.