[Python-3000] PEP 3106: Revamping dict.keys(), .values() and .items()

[Guido van Rossum]

On 12/19/06, Guido van Rossum <guido at python.org> wrote:
> I've written a quick version of PEP 3106, which expresses my ideas
> about how the dict methods to access keys, values and items should be
> redone.

Thanks for all the comments. The new version is in svn:
http://svn.python.org/view/peps/trunk/pep-3106.txt?view=markup

At some point it will appear on python.org: http://python.org/dev/peps/pep-3106/

Most issues brought up are either resolved or clarified in the new
PEP, or explicitly added as open issues. I have strawman answers for
most open issues except for the class names, which I'll leave up to
whoever wants to implement this (except I *don't* like Neal's
suggestion to name them dict.Keys etc.; that's a rather Javaesque use
of a class as a namespace that feels unpythonic to me. OTOH the
collections module seems a fine resting place.)

Some specific answers to issues brought up that you may not easily
find back in the new PEP, and some new (perhaps off-topic) thoughts:

- Adding list.discard() is a separate issue and doesn't have to wait
for Py3k. I think it's a reasonable suggestion.

- I am beginning to wonder if copy() methods should be discouraged in
general in favor of explicitly naming the result type you want; e.g.
to copy a set x you would write set(x) instead of x.copy(). This makes
"generic" copying a bit harder, e.g. suppose you have an x that could
be either a set or a frozenset and you want a copy that has the same
type as x; but I'm not actually convinced that there are a lot of use
cases for that outside the copy module. But this is also off-topic. I
believe Alex Martelli may have some ideas on this, since I believe he
dislikes using x[:] to copy a list and prefers list(x).

- OTOH, d_items.copy() could easily be implemented as
self.__d.copy().items(). (I forgot to add this to the PEP.) I wouldn't
want to do something like this for copying keys or values, but for
items it seems to be fast and space-efficient, since the dict copy
doesn't use actual tuples for its items.

- I expect that some refinements to this PEP will become apparent once
we have a solid proposal for ABCs (which I fully intend to support).

- Talin asked for values to be list-like rather than set-like, and
proposes bags. Well, I thought bags and multisets are the same thing
(unordered lists that may contain duplicates). I really don't want
them to be list-like since that implies an ordering (albeit arbitrary)
and an O(1) indexing (v[i]) operation. I believe the Java Collections
Framework calls this a Collection -- it is a little bit more than an
iterable since it has a length and a membership test, but it doesn't
promise that these are efficient. That's pretty close to what d_values
does in the new PEP, except I also added an implementation of equality
(albeit an inefficient one due to the potential unhashability of
values).

- Again off-topic: Java's add() method returns true if the collection
was changed; its remove() method acts like our discard() but again
returns true if the collection was changed. Would it be worth to copy
this API style?

If I left your specific suggestion or question unaddressed or
unanswered, please send it again (after re-reading the PEP, of
course).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)