From 7ecd06cd4ded47666a498f8b610f4def5a832667 Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Mon, 8 Oct 2007 03:15:35 +0000 Subject: [PATCH] Typos and clarifications detected by Mark Summerfield. --- pep-3106.txt | 9 +++++---- pep-3119.txt | 39 +++++++++++++++++++++------------------ 2 files changed, 26 insertions(+), 22 deletions(-) diff --git a/pep-3106.txt b/pep-3106.txt index ca090a1d5..bb7501513 100644 --- a/pep-3106.txt +++ b/pep-3106.txt @@ -15,7 +15,7 @@ Abstract 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 @@ this:: 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 @@ have to write the iter() call because it is implied by a for-loop. 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 @@ The view objects are not directly mutable, but don't implement __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 diff --git a/pep-3119.txt b/pep-3119.txt index aa0a48a2a..df7fddba2 100644 --- a/pep-3119.txt +++ b/pep-3119.txt @@ -244,7 +244,7 @@ The ``ABCMeta`` class overrides ``__instancecheck__`` and ``__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 @@ abstract, and attempts to instantiate it will raise ``TypeError``. (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 @@ It can be used in two ways:: 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 @@ These abstract classes represent single methods like ``__iter__`` or 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 @@ These abstract classes represent single methods like ``__iter__`` or 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 @@ Sets 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 @@ type ``frozenset`` derives from ``Set`` and ``Hashable``. 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 @@ type ``frozenset`` derives from ``Set`` and ``Hashable``. 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.