{} for set notation

Nick Vatamaniuc vatamane at gmail.com
Fri Jul 14 13:40:26 EDT 2006


tic-tacs,

But how often does one use a list or a tuple when a set is actually
more meaningful? -- Probably more than expected, because traditionally
comming from C and in the older Python versions there were no sets.

 A prime example are the keys of the dictionary. They are a _set_ not a
list. If a list is returned by the keys() method, one might assume that
somehow there is a special order to the keys.

 Or, for example, the other day I looked at some of my old code at some
point I was gathering values for removal and I was using a list then I
was doing "if deleteme is not in removelist:
removelist.append(deleteme)". And I remember doing that more than one
time. Looking back I would have used sets a lot more often especially
if they had a quick easy notation like {1,2,3}.

Another example is typical constant-like parameters. Again coming from
Java and C we have been using FLAG1=1, FLAG2=1<<1, FLAG3=1<<2 then
setting FLAG=FLAG1|FLAG2. This uses the bit arithmetics along with the
bitwise 'or' operator. It is fine for C but in Python it looks odd.
What we really want to say is that FLAG={FLAG1, FLAG2, FLAG3}. A new
user would be puzzled by FLAG2=1<<1 or how come FLAG2=2 and FLAG3=4?.

In general a set is a fundamental datatype. It was fundamental enough
to include in Python as a builtin. Even though there was already the
dictionary the list and the tuple. For completeness I think a set
deserves its own notation. Once it has it, you'd be surprised how many
people would more likely to use than if they had to type set([...]).


Regards,
Nick Vatamaniuc

tac-tics wrote:
> Nick Vatamaniuc wrote:
> > I really like the set notation idea. Now that sets are first class
> > "citizens" along with dicts, lists and tuples I think they should be
> > used when it makes sense to use them
>
> In actual usage, though, how often is it strictly required one uses a
> set over a list? It is similar to how queue and stack are not in the
> default namespace. Unless you really need to ensure no one is allowed
> to make random access changes to your data, a list with push and pop is
> really all you need. I beleive the same applies in regards to sets.




More information about the Python-list mailing list