Re: Dictionary .keys() and .values() should return a set [with Python 3000 in mind]

<vatamane@xxxxxxxxx> wrote in message
news:1151784117.119515.310100@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This has been bothering me for a while. Just want to find out if it
just me or perhaps others have thought of this too: Why shouldn't the
keyset of a dictionary be represented as a set instead of a list?

I think this is an interesting suggestion. Of course, the current situation
is as much a product of historical progression as anything: lists and dicts
pre-date sets, so the collection of keys had to be returned as a list.
Since lists also carry some concept of order to them, the documentation for
the list returned by dict.keys() went out of its way to say that the order
of the elements in the dict.keys() list had no bearing on the dict, the
insertion order of entries, or anything else, that the order of keys was
purely arbitrary.

In fact, there is not a little irony to this proposal, since it seems it was
just a few months ago that c.l.py had just about weekly requests for how to
create an "ordered dict," with various ideas of how a dict should be
ordered, but most intended to preserve the order of insertion of items into
the dict. And now here we have just about the opposite proposal - dicts
should not only *not* be ordered, they should revel in their disorderliness.

I liked the example in which the OP (of this thread) wanted to compare the
keys from two different dicts, for equality of keys. Since the keys()
method returns a set of indeterminate order, we can't simply perform
dictA.keys() == dictB.keys(). But how often does this really happen? In
practice, I think the keys of a dict, when this collection is used at all,
are usually sorted and then iterated over, usually to prettyprint the keys
and values in the dict. Internally, this set of items shouldn't even exist
as a separate data structure - the dict's keys are merely labels on nodes in
some sort of hash tree.

Now that we really do have sets in Python, if one were to design dicts all
over again, it does seem like set would be a better choice than list for the
type returned by the keys() method. To preserve compatibility, would a
second method, keyset(), do the trick? The OP used this term himself,
referring to "the keyset of the dictionary". Still given the few cases
where I would access this as a true set, using "set(dictA.keys())" doesn't
seem to be that big a hardship, and its obviousness will probably undercut
any push for a separate keyset() method.

-- Paul


.

Relevant Pages

  • Re: Why are tuples immutable?
    ... Nothing forces me to have two lists as equal just because there elements ... Any time I want to use the dict elsewhere, ... > pass not only the dict itself, but a list of keys to the dict. ... > memory leaks in C aren't a problem because you've told programmers to ...
    (comp.lang.python)
  • Re: Newbie help with array handling
    ... The problem is that Python doesn't have a built-in sorted dictionary ... then you can just use a list of lists ... If you need the dict characteristics a lot, then you may use a dict ... (but keys must be hashable objects): ...
    (comp.lang.python)
  • Re: On text processing
    ... that results in ugly python code and I'm sure there is a simple ... structured as more than just lists of tokens. ... Using pyparsing's Dict ... You can adjust the syntax definition of keys and values to fit your ...
    (comp.lang.python)
  • Re: dict critique
    ... > as using lappend on the dictionary, ... > sure, that keys remain unique. ... Well, if you want [dict add], write a short TIP. ... whereas lists just need a replace-range-with-list operation. ...
    (comp.lang.tcl)
  • RE: Dictionary .keys() and .values() should return a set [with Python3000 in mind]
    ... keyset of a dictionary be represented as a set instead of a list? ... Suggestings included making keys(), etc return an iterator, and getting ... same behaviour as the lists returned from keys, ... overhead of creating a list and populating it - they would be backed by ...
    (comp.lang.python)