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

[Guido van Rossum]

2008/9/12 skip <skip at pobox.com>:
> 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

What's the purpose of the "order by key" clauses here? Doesn't that force
the return order? Perhaps you meant to leave those out?

> 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()]".

That last example is unnecessarily odd -- why does it put the values first?

> 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?

I probably wrote an early version of that text, and I meant it to apply to
dicts only. (In general this section is a description of the dict
implementation, not of the mapping concept.) I do want to keep this
guarantee for dicts, for the following reasons: (a) it's very unlikely it
will ever change in CPython (note the caveat of no changes); (b) users will
write working code that subtly depends on it, without even realizing it; (c)
no amount of documentation is going to get those users not to make that
assumption; (d) but documenting this requirement (for dicts) is sure to draw
the attention of the implementers of alternative Python versions, who will
have to implement this so as not to break the implicit assumptions of users
in (b).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080912/4e09e23c/attachment-0001.htm>