470,647 Members | 1,183 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,647 developers. It's quick & easy.

proposed proposal: set.values()

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?
Mar 30 '06 #1
6 1322

"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
news:7x***************@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

Mar 31 '06 #2
"Terry Reedy" <tj*****@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
and sets.
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).
I'd say keys is incorrect, since sets don't have keys:
import sets
s=sets.Set((1,2,3))
s[1]

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 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.
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, ,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.


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.
Mar 31 '06 #3
Paul Rubin wrote:
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
and sets.


if y is a dict, "x in y" looks for a matching key, not for a matching value.

</F>

Mar 31 '06 #4
"Fredrik Lundh" <fr*****@pythonware.com> writes:
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
and sets.


if y is a dict, "x in y" looks for a matching key, not for a
matching value.


Good point, the duck typing mismatches on "x in y" and there's nothing
that can be done about that.

Imagine a Bag (multiset) object; it can have multiple occurrences of a
single value. A keys() operation on it should return unique items,
but values() should return the multiple occurrences.
Mar 31 '06 #5
"Terry Reedy" <tj*****@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
and sets.
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). I'd say keys is incorrect, since sets don't have keys:
import sets
s=sets.Set((1,2,3))
s[1]
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 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.
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, ,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.

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.

Mar 31 '06 #6
Paul Rubin wrote:
"Terry Reedy" <tj*****@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
and sets.


You could just do the following...

class vset(set): .... values = set.copy
....
s = vset([1,2,3]) s.values() vset([1, 2, 3])
for x in s.values():

.... x
....
1
2
3
Cheers,
Ron
Mar 31 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

29 posts views Thread by C A Upsdell | last post: by
108 posts views Thread by Bryan Olson | last post: by
2 posts views Thread by Richard Cornford | last post: by
47 posts views Thread by Pierre Barbier de Reuille | last post: by
3 posts views Thread by James J. Besemer | last post: by
reply views Thread by warner | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.