[Python-Dev] syntactic support for sets

[Josiah Carlson]

Donovan Baarda <abo at minkirri.apana.org.au> wrote:
> 
> On Fri, 2006-02-03 at 09:00 -0800, Josiah Carlson wrote:
> [...]
> > Sets are tacked on.  That's why you need to use 'import sets' to get to
> > them, in a similar fashion that you need to use 'import array' to get
> > access to C-like arrays.
> 
> No you don't;
> 
> $ python
> Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
> [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> v=set((1,2,3))
> >>> f=frozenset(v)
> >>>
> 
> set and frozenset are now builtin.

Indeed they are.  My apologies for being incorrect, I'm still using 2.3
for all of my commercial work.


> > I personally object to making syntax for sets for the same reasons I
> > object to making arrays, heapqs, Queues, deques, or any of the other
> > data structure-defining modules in the standard library into syntax.
> 
> Nuff was a fairy... though I guess it depends on where you draw the
> line; should [1,2,3] be list(1,2,3)?

Who is "Nuff"?

Along the lines of "not every x line function should be a builtin", "not
every builtin should have syntax".  I think that sets have particular
uses, but I don't believe those uses are sufficiently varied enough to
warrant the creation of a syntax.  I suggest that people take a walk
through their code. How often do you use other sequence and/or mapping
types? How many lists, tuples and dicts are there?  How many sets? Ok,
now how many set literals?

Syntax for sets is only really useful for the equivalent of a set
literal, and with minimal syntax for a set literal being some sort of
start and ending character pair, the only thing gained is a 3 key
reduction in the amount of typing necessary, and a possible compiler
optimization to call the set creation code instead of the local, global,
then builtin namespaces.

Essentially, I'm saying that "set(...)" isn't significantly worse than
"{...}" (or some other pair) for set creation.  One can say the same
thing about list(), tuple(), and dict(), but I think that their millions
of uses far overwhelms the minimal uses (and usage) of set(), and puts
them in a completely different class.


 - Josiah