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

[guido.van.rossum]

Author: guido.van.rossum
Date: Sun Dec 24 02:33:16 2006
New Revision: 53157

Modified:
   peps/trunk/pep-3106.txt
Log:
- Clarify that the ordering of keys, values and items is compatible.
- Note that comparing two d_items instances could compare the underlying
  dicts.
- Ask whether we need more of a motivation.
- Observe that we could cache+reuse the keys/values/items objects.


Modified: peps/trunk/pep-3106.txt
==============================================================================
--- peps/trunk/pep-3106.txt	(original)
+++ peps/trunk/pep-3106.txt	Sun Dec 24 02:33:16 2006
@@ -23,6 +23,7 @@
 The approach is inspired by that taken in the Java Collections
 Framework [1]_.
 
+
 Introduction
 ============
 
@@ -243,6 +244,7 @@
                 return True
             if not isinstance(other, d_items):
                 return NotImplemented
+            # XXX We could also just compare the underlying dicts...
             if len(self) != len(other):
                 return False
             for item in self:
@@ -306,13 +308,32 @@
 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
+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
+isn't modified).  This can be expressed by the following invariant::
+
+    list(d.items()) == list(zip(d.keys(), d.values()))
+
 
 Open Issues
 ===========
 
+Do we need more of a motivation?  I would think that being able to do
+set operations on keys and items without having to copy them should
+speak for itself.
+
 I've left out the implementation of various set operations.  These
 could still present 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
+refers.  Is this worth having extra slots in the dict object for?
+Should that be a weak reference or should the d_keys (etc.) object
+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).