[Python-checkins] r53836 - peps/trunk/pep-0000.txt peps/trunk/pep-3106.txt
guido.van.rossum
python-checkins at python.org
Wed Feb 21 00:32:42 CET 2007
Author: guido.van.rossum
Date: Wed Feb 21 00:32:28 2007
New Revision: 53836
Modified:
peps/trunk/pep-0000.txt
peps/trunk/pep-3106.txt
Log:
Sorry, PEP 3106 is not yet accepted. Also removed mutating operations
and added some clarifications.
Modified: peps/trunk/pep-0000.txt
==============================================================================
--- peps/trunk/pep-0000.txt (original)
+++ peps/trunk/pep-0000.txt Wed Feb 21 00:32:28 2007
@@ -78,7 +78,7 @@
Accepted PEPs (accepted; may not be implemented yet)
SA 3102 Keyword-Only Arguments Talin
- SA 3106 Revamping dict.keys(), .values() and .items() GvR
+ S 3106 Revamping dict.keys(), .values() and .items() GvR
SA 3107 Function Annotations Winter, Lownds
SA 3109 Raising Exceptions in Python 3000 Winter
SA 3110 Catching Exceptions in Python 3000 Winter
@@ -449,7 +449,7 @@
S 3103 A Switch/Case Statement GvR
S 3104 Access to Names in Outer Scopes Yee
SF 3105 Make print a function Brandl
- SA 3106 Revamping dict.keys(), .values() and .items() GvR
+ S 3106 Revamping dict.keys(), .values() and .items() GvR
SA 3107 Function Annotations Winter, Lownds
I 3108 Standard Library Reorganization Cannon
SA 3109 Raising Exceptions in Python 3000 Winter
Modified: peps/trunk/pep-3106.txt
==============================================================================
--- peps/trunk/pep-3106.txt (original)
+++ peps/trunk/pep-3106.txt Wed Feb 21 00:32:28 2007
@@ -3,7 +3,7 @@
Version: $Revision$
Last-Modified: $Date$
Author: Guido van Rossum
-Status: Accepted
+Status: Draft
Type: Standards
Content-Type: text/x-rst
Created: 19-Dec-2006
@@ -14,11 +14,10 @@
========
This PEP proposes to change the .keys(), .values() and .items()
-methods of the built-in dict type to return a set-like or
-multiset-like (== bag-like) object whose contents are derived of the
-underlying dictionary rather than a list which is a copy of the keys,
-etc.; and to remove the .iterkeys(), .itervalues() and .iteritems()
-methods.
+methods of the built-in dict type to return a set-like or unordered
+container object whose contents are derived of the underlying
+dictionary rather than a list which is a copy of the keys, etc.; and
+to remove the .iterkeys(), .itervalues() and .iteritems() methods.
The approach is inspired by that taken in the Java Collections
Framework [1]_.
@@ -72,25 +71,16 @@
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 with limited mutability; they allow removing elements, but not
-adding them. Removing an item from these sets removes it from the
-underlying dict. The object returned by the values() method behaves
-like a multiset (Java calls this a Collection). It does not allow
-removing elements, because a value might occur multiple times and the
-implementation wouldn't know which key to remove from the underlying
-dict. (The Java Collections Framework has a way around this by
-removing from an iterator, but I see no practical use case for that
-functionality.)
+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.
Because of the set behavior, it will be possible to check whether two
dicts have the same keys by simply testing::
if a.keys() == b.keys(): ...
-and similarly for values. (Two multisets are deemed equal if they
-have the same elements with the same cardinalities, e.g. the multiset
-{1, 2, 2} is equal to the multiset {2, 1, 2} but differs from the
-multiset {1, 2}.)
+and similarly for .items().
These operations are thread-safe only to the extent that using them in
a thread-unsafe way may cause an exception but will not cause
@@ -145,26 +135,12 @@
for key in self.__d:
yield key
- def remove(self, key):
- del self.__d[key]
-
- def discard(self, key):
- if key in self:
- self.remove(key)
-
- def pop(self):
- return self.__d.popitem()[0]
-
- def clear(self):
- self.__d.clear()
-
# The following operations should be implemented to be
# compatible with sets; this can be done by exploiting
# the above primitive operations:
#
# <, <=, ==, !=, >=, > (returning a bool)
# &, |, ^, - (returning a new, real set object)
- # &=, -= (updating in place and returning self; but not |=, ^=)
#
# as well as their method counterparts (.union(), etc.).
#
@@ -191,23 +167,6 @@
for key in self.__d:
yield key, self.__d[key]
- def remove(self, (key, value)):
- if (key, value) not in self:
- raise KeyError((key, value))
- del self.__d[key]
-
- def discard(self, item):
- # Defined in terms of 'in' and .remove() so overriding
- # those will update discard appropriately.
- if item in self:
- self.remove(item)
-
- def pop(self):
- return self.__d.popitem()
-
- def clear(self):
- self.__d.clear()
-
# As well as the set operations mentioned for d_keys above.
# However the specifications suggested there will not work if
# the values aren't hashable. Fortunately, the operations can
@@ -288,11 +247,8 @@
# XXX Sometimes this could be optimized, but these are the
# semantics: we can't depend on the values to be hashable
# or comparable.
- o = list(other)
for x in self:
- try:
- o.remove(x)
- except ValueError:
+ if not o in other:
return False
return True
@@ -302,13 +258,21 @@
result = not result
return result
-Note that we don't implement .copy() -- the presence of a .copy()
+Notes:
+
+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.
+
+We don't implement .copy() -- the presence of a .copy()
method suggests that the copy has the same type as the original, but
that's not feasible without copying the underlying dict. If you want
a copy of a specific type, like list or set, you can just pass one
of the above to the list() or set() constructor.
-Also note that the specification implies that the order in which items
+The specification implies that the order in which items
are returned by .keys(), .values() and .items() is the same (just as
it was in Python 2.x), because the order is all derived from the dict
iterator (which is presumably arbitrary but stable as long as a dict
@@ -325,7 +289,7 @@
speak for itself.
I've left out the implementation of various set operations. These
-could still present surprises.
+could still present small surprises.
It would be okay if multiple calls to d.keys() (etc.) returned the
same object, since the object's only state is the dict to which it
@@ -334,11 +298,6 @@
live forever once created? Strawman: probably not worth the extra
slots in every dict.
-Should d_values have mutating methods (pop(), clear())? Strawman: no.
-
-Should d_values implement set operations (as defined for multisets).
-Strawman: no.
-
Should d_keys, d_values and d_items have a public instance variable or
method through which one can retrieve the underlying dict? Strawman:
yes (but what should it be called?).
More information about the Python-checkins
mailing list