Why is dictionary.keys() a list and not a set?

Christoph Zwerschke cito at online.de
Thu Nov 24 14:06:46 EST 2005


Alex Martelli wrote:

> Absolutely not in my use cases.  The typical reason I'm asking for
> .values() is because each value is a count (e.g. of how many time the
> key has occurred) and I want the total, so the typical idiom is
> sum(d.values()) -- getting a result set would be an utter disaster, and
> should I ever want it, set(d.values()) is absolutely trivial to code.

Agree. This reason alone is enough for values() to be a list, besides 
the problem that it can contain unhashable values.

> Note that in both cases I don't need a LIST, just an ITERATOR, so
> itervalues would do just as well (and probably faster) except it looks
> more cluttered and by a tiny margin less readable -- "the sum of the
> values" rolls off the tongue, "the sum of the itervalues" doesn't!-)
> So, the direction of change for Python 3000, when backwards
> compatibility can be broken, is to return iterators rather than lists.
> At that time, should you ever want a list, you'll say so explicitly, as
> you do now when you want a set, i.e. list(d.values())

Sounds reasonable.

> In Python today 'in' doesn't necessarily mean set membership, but some
> fuzzier notion of "presence in container"; e..g., you can code
> 
> 'zap' in 'bazapper'
> 
> and get the result True (while 'paz' in 'bazapper' would be False, even
> though, if you thought of the strings as SETS rather than SEQUENCES of
> characters, that would be absurd).  So far, strings (plain and unicode)
> are the only containers that read 'in' this way (presence of subsequence
> rather than of single item), but one example should be enough to show
> that "set membership" isn't exactly what the 'in' operator means.

In this case, I would interpret the set on which 'in' operates as the 
set of all substrings of the given string to have peace for my soul ;-)

> You appear to have a strange notion of "derived data type".  In what
> sense, for example, would a list BE-A set?  It breaks all kind of class
> invariants, e.g. "number of items is identical to number of distinct
> items", commutativity of addition, etc..

Sorry. Your're right. In the computer world, sets are derived from lists 
(collections). In mathematics, lists are derived from sets. Here, you 
would define the list [1, 1] as the set {1, {1, 1}} (you see, the 
cardinality is the same). Yes, mathematics is strange ;-) Actually, in 
mathematics, everything is a set and set theory is the "theory of 
everything". When I grew up pedagogues here in Germany even believed it 
would be best if kids learn set theory and draw venn diagrams before 
they learn arithmetics... We were tortured with that kind of things in 
the first class. Probably I'm still suffering from the late damages of 
that treatment.

-- Christoph



More information about the Python-list mailing list