why does UserDict.DictMixin use keys instead of __iter__?

John Machin sjmachin at lexicon.net
Tue Jan 4 21:40:15 CET 2005

Steven Bethard wrote:
> John Machin wrote:
> > Steven Bethard wrote:
> >
> >>So I was looking at the Language Reference's discussion about
> >>emulating container types[1], and nowhere in it does it mention
> >> .keys() is part of the container protocol.
> >
> > I don't see any reference to a "container protocol".
> Sorry, I extrapolated "container protocol" from this statement:
> "Containers usually are sequences (such as lists or tuples) or
> (like dictionaries), but can represent other containers as well. The
> first set of methods is used either to emulate a sequence or to
> a mapping"
> and the fact that there is a "sequence protocol" and a "mapping
> But all I was really reading from this statement was that the "first
> of methods" (__len__, __getitem__, __setitem__, __delitem__ and
> __iter__) were more integral than the second set of methods (keys(),
> values(), ...).
> > What I do see is
> > (1) """It is also recommended that mappings provide the methods
> > ..."""
> You skipped the remaining 13 methods in this list:
> "It is also recommended that mappings provide the methods keys(),
> values(), items(), has_key(), get(), clear(), setdefault(),
> itervalues(), iteritems(), pop(), popitem(), copy(), and update()
> behaving similar to those for Python's standard dictionary objects."
> This is the "second set of methods" I mentioned above.  I don't
> understand why the creators of UserDict.DictMixin decided that
> from the second list, is more important than __iter__, from the first
> >>Because of this, I would assume that to
> >>use UserDict.DictMixin correctly, a class would only need to define
> >>__getitem__, __setitem__, __delitem__ and __iter__.
> >
> >
> > So I can't see why would you assume that, given that the docs say
> > effect "you supply get/set/del + keys as the building blocks, the
> > DictMixin class will provide the remainder". This message is
> > in the docs for UserDict itself.
> Sorry, my intent was not to say that I didn't know from the docs that

> UserDict.DictMixin required keys().  Clearly it's documented.

Sorry, the combination of (a) "assume X where not(X) is documented" and
(b) posting of tracebacks that demonstrated behaviour that is both
expected and documented lead to my making an unwarranted assumption :-)

> My
> question was *why* does it use keys()?  Why use keys() when keys()
> be derived from __iter__, and __iter__ IMHO looks to be a more basic
> part of the mapping protocol.

Now that I understand your question: Hmmm, good question. __iter__
arrived (2.2) before DictMixin (2.3), so primacy is not the reason.
Ease of implementation by the user of DictMixin: probably not, "yield
akey" vs "alist.append(akey)" -- not much in it in Python, different
story in C, but a C extension wouldn't be using DictMixin anyway.
> > In any case, isn't UserDict past history? Why are you mucking about
> > with it?
> UserDict is past history, but DictMixin isn't.

OK, I'll rephrase: what is your interest in DictMixin?

My interest: I'm into mappings that provide an approximate match
capability, and have a few different data structures that I'd like to
implement as C types in a unified manner. The plot includes a base type
that, similarly to DictMixin, provides all the non-basic methods.

More information about the Python-list mailing list