[Python-Dev] syntactic support for sets (original) (raw)

Josiah Carlson jcarlson at uci.edu
Fri Feb 3 20:56:55 CET 2006

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.

More information about the Python-Dev mailing list