proposed proposal: set.values()

[Terry Reedy]

"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message 
news:7x1wwjfr9k.fsf_-_ at ruckus.brouhaha.com...
> 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