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 that > >> .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 mappings > (like dictionaries), but can represent other containers as well. The > first set of methods is used either to emulate a sequence or to emulate > a mapping" > > and the fact that there is a "sequence protocol" and a "mapping protocol". > > But all I was really reading from this statement was that the "first set > 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 keys(), > > ...""" > > 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(), iterkeys(), > 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 keys(), > from the second list, is more important than __iter__, from the first list. > > > >>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 in > > effect "you supply get/set/del + keys as the building blocks, the > > DictMixin class will provide the remainder". This message is reinforced > > 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() can > 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. -- http://mail.python.org/mailman/listinfo/python-list
