Typos and clarifications detected by Mark Summerfield.
This commit is contained in:
parent
7645efeee7
commit
7ecd06cd4d
|
@ -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
|
||||
|
|
39
pep-3119.txt
39
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.
|
||||
|
||||
|
|
Loading…
Reference in New Issue