"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message news:[EMAIL PROTECTED] > I'm thinking of proposing that a values method be added to set > objects, analogously with dicts. If x is a set, x.values() would be > the same as list(x). This feels logical, and it would allow unified > treatment of dicts and sets in some contexts. Any objections?
1. It is pure duplication that *adds* keystrokes. 2. It copies the wrong aspect of dict. A set is like dict.keys (no duplicates, hashable), not dict.values (duplicates and non-hashables ok). 3. It copies a workaround. Conceptually, dict.keys() and dict.items() should each be a set, not list, and would have been if Python had had sets at birth. Dict.values() should be a multiset or bag. The order of any is purely artificial and random. Set.keys() or set.values() should be the set itself. 4. The workaround will change or even better go away. In 3.0, ,keys, .values and .items not be lists. The initial proposal was to replace them with iterators (the current iterkeys, etc). A current proposal (still in development) is for an iterable set- or multiset-like view on the underlying dict. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
