proposed proposal: set.values()
//phr.cx at -dot-invalid.no-spam.invalid
Fri Mar 31 12:01:56 CEST 2006
"Terry Reedy" <tjreedy at udel.edu> writes:
> 1. It is pure duplication that *adds* keystrokes.
Nobody says you shouldn't use list(s) if you know you're dealing with
a set. The idea of s.values() is so you can duck-type between dicts
> 2. It copies the wrong aspect of dict. A set is like dict.keys (no
> duplicates, hashable), not dict.values (duplicates and non-hashables
I'd say keys is incorrect, since sets don't have keys:
> import sets
> Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unindexable object
I don't think it's important that some values that can occur in dicts
(e.g. non-hashables) can't occur in sets. There are similarly values
for complex numbers that can't be expressed as floats, but that
doesn't mean __add__ shouldn't work on both.
> 3. It copies a workaround. Conceptually, dict.keys() and
> should each be a set, not list, and would have been if Python had
> at birth. Dict.values() should be a multiset or bag. The order of
> purely artificial and random. Set.keys() or set.values() should be
I guess it's ok if sets.items() is the same as sets.values(). Sets
don't have keys. dict.values() is what it is for historical reasons
as you state, and would be hard to change, so it makes sense for
set.values() to work the same way.
> 4. The workaround will change or even better go away. In 3.0,
> .values and .items not be lists. The initial proposal was to
> with iterators (the current iterkeys, etc). A current proposal
> development) is for an iterable set- or multiset-like view on the
> underlying dict.
I hadn't heard of this but it does make some sense. However,
sets.values (and maybe sets.items) should be treated the same way,
under my proposed proposal.
More information about the Python-list