[Python-3000] How much should non-dict mappings behave like dict?

[Eric Smith]

skip at pobox.com wrote:
> In issue 3783 (http://bugs.python.org/issue3783) the question was raised
> about whether or not it's worthwhile making this guarantee:
> 
>     zip(d.keys(), d.values()) == d.items()
> 
> in the face of no changes to the mapping object.  At issue is whether the
> SQL query should force a predictable order on the keys and values fetched
> from the database or if that's just wasted CPU cycles.  Making it concrete,
> should these two SELECT statements force a consistent ordering on the keys
> and values retrieved from the database:
> 
>     select key from dict order by key
>     select value from dict order by key
> 
> Currently SQLite does return the keys and values in the same, predictable,
> order, but doesn't guarantee that behavior (so it could change in the
> future).
> 
> While the discussion in the issue is related to this nascent dbm.sqlite
> module, I think it's worth considering the more general issue of how
> behavior non-dict mapping types should be required to share with the dict
> type.
> 
> In the section "Mapping Types -- dict" in the 2.5.2 library reference:
> 
>     http://docs.python.org/lib/typesmapping.html
> 
> there is a footnote about ordering of keys and values:
> 
>     Keys and values are listed in an arbitrary order which is non-random,
>     varies across Python implementations, and depends on the dictionary's
>     history of insertions and deletions. If items(), keys(), values(),
>     iteritems(), iterkeys(), and itervalues() are called with no intervening
>     modifications to the dictionary, the lists will directly
>     correspond. This allows the creation of (value, key) pairs using zip():
>     "pairs = zip(a.values(), a.keys())". The same relationship holds for the
>     iterkeys() and itervalues() methods: "pairs = zip(a.itervalues(),
>     a.iterkeys())" provides the same value for pairs. Another way to create
>     the same list is "pairs = [(v, k) for (k, v) in a.iteritems()]".
> 
> It's not entirely clear if this page is meant to apply just to dictionaries
> or if (to the extent possible) it should apply to all mapping types.  I'm of
> the opinion it should apply more broadly.  Others are not of that opinion.
> Should the documentation be more explicit about this?
> 
> Comments?  

I think the guarantee should be removed from dicts, and in any event 
shouldn't be a requirement for other mappings. I think the ordering 
should be an implementation detail, just as the part that says "depends 
on the dictionary's history of insertions and deletions" need not be 
true for all mapping implementations. I wouldn't want the performance of 
any dictionary or any mapping type bound by these constraints, 
especially one that might be large and in a database.

Given items(), I don't see why you'd ever need "zip(a.keys(), 
a.values())" to work.

Antoine makes many of these same points in the issue comments.

But then I have no current or imagined use case that would rely on this 
behavior. Others may of course disagree. Has anyone ever seen code that 
relies on this? Might such code predate items()?

Eric.