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

Neal Norwitz nnorwitz at gmail.com
Wed Dec 20 07:39:07 CET 2006

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.
> The text is in svn:
> http://svn.python.org/view/peps/trunk/pep-3106.txt?rev=53096&view=markup
> At some point it will appear on python.org: http://python.org/dev/peps/pep-3106/

The idea is that code that currently (in 2.x) reads::

    for x in d.iterkeys(): ...

should be rewritten as::

    for x in d.keys(): ...

Is this really the best example?  Wouldn't this be better written as
for x in d: ... ?
Maybe replace keys with items or values?

I think I know the answer to this question, but I just want it explicit:

        def copy(self):
            return set(self)

Should that be set or frozenset (in all the classes)?  Also, should
self.__d be passed to set()?

In d_keys:
        def discard(self, key):
            if key in self:

You could use self.__d here.  It's an optimization and doesn't really
apply to the others so I'm not sure the change is worth it.

It's interesting that you add a discard method.  Would you also like a
similar method added to lists?  (I know these are conceptual sets, but
in the past I think I've wanted discard functionality more than
remove.  I wonder if this is somewhat similar to str.find vs

In d_values:
        def __contains__(self, value):
            # Slow!  Do we even want to implement this?

KISS.  I'd rather keep the interface as small as possible at first,
especially with something like this.  Let the interface grow if we
find it lacking.

I'm soliciting better names than d_keys, d_values and d_items; these
classes will be public so that their implementations may be reused by
the .keys(), .values() and .items() methods of other mappings.  (Or
should they?)

I'm not sure if they should be public or not, but what about just:


If we have a mapping ABC, that would be a more appropriate place.
Have you decided if there will be ABCs like:  mapping, sequence,
number, etc.?  These seem to make more sense if type annotations would
be provided as part of the syntax.

Or perhaps there could be a mapping module?


More information about the Python-3000 mailing list