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. -- http://mail.python.org/mailman/listinfo/python-list