[Python-3000] sets in P3K?

Guido van Rossum guido at python.org
Thu Apr 27 00:10:02 CEST 2006


On 4/26/06, Josiah Carlson <jcarlson at uci.edu> wrote:
>
> Edward Loper <edloper at gradient.cis.upenn.edu> wrote:
> >
> > I think that a significant motivation for people that propose set
> > literals is that the following is just plain ugly:
> >
> >     s = set([1,2,3])
> >
> > It seems much more natural to write:
> >
> >     s = set(1, 2, 3)
>
> I agree.
>
> > However, it is fairly common to want to build a set from a collection,
> > an iterator, or a genexp.  With the current notation, all three of these
> > are easy.  But with this "more natural" notation, they're no longer
> > possible without resorting to varargs (which would create an unnecessary
> > imtermediary tuple).
>
> Right now you are manually creating an intermediate list or tuple to
> pass to set, so this wouldn't seem to be a significant change to me
> (it's just an argument semantic addition).

I have no idea what you mean by "argument semantic addition".

I don't think this form (set(1, 2, 3)) will ever fly, because it would
makes set(x) ambiguous. Currently, this interprets x as an iterable
and produces a set with the elements produced by iterating over x. But
if set(x, y) is a set of two elements, then set(x) should be a set of
one element, *regardless of the type of x*.

Curiously, min() and max() successfully use the same overloading.
However, these don't have the same problem, because min() or max() of
one value makes no sense, so it's safe to define these such that if
they are called with a single argument, the argument is assumed to be
an iterable. But constructing a set() of one value *does* make sense
(and already has a meaning) so the overloading fails here.

I find the many attempts to come up with a reasonable way to construct
a set from a list of given values; I hope that {x, y} can still come
out as a winner, with set(x) useful to construct a set from a
pre-existing iterable. Note that set(range(10)) is a set with 10
elements; {range(10)} of course would be a set with one element. The
same differences exists between list(range(10)) and [range(10)].

Sets will become more "mainstream" in Python 3000 if the views
proposal is accepted; once dict.keys() and dict.items() return set
views (i.e. objects that implement most of the set API but whose
contents are linked to the underlying dict instance), the awareness of
sets is bound to increase.

Regarding set vs. frozenset: the Google query ``frozenset
filetype:py'' returns only 160 results. It's not fair to compare this
to the 230K results for "set filetype:py" because set is also a common
method name and a common word, but still it's an underwhelming number
of results. I found 70K results for tuple and dict each, 200K+ for
list, 50K for unicode. Frozen sets just aren't all that popular.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list