I agree -- I find myself NEEDING sets more and more. I use them with this idiom quite often. Once they become more widely available (i.e. Python 2.3 is installed everywhere), I will use them almost as much as lists I bet.
So any solution IMO needs to at least encompass sets. But preferably something like the Dict with Default approach which encompasses all possibilities. Roose > I am more than sure you are right about this. But, please keep in mind > that you and we all have come very, very accustomed to using lists for > everything and the kitchen sink in Python. > > Lists where there from the beginning of Python, and even before the > birth of Python; very powerfull, well implemented and theoretically > well founded datastructures - I heared there is a whole language based > on list processing. *pun intended* > > sets on the other hand --- I know, in mathematics they have a deep, > long history. But in programming? Yeah, in SQL and ABAP/4 basically > you are doing set operations on every join. But its rather uncommon to > call it set. > > With 2.3 Python grew a set module. And, in ONLY ONE revision it got > promoted to a buildin type - a honour only those who read c.l.p.d. > regualary can value correctly. > > And sets are SO NATURALLY for a lot of problems ... I never thought of > replacing my "list in dict" constructs with sets before, BUT .... > there are 90% of problem domains where order is not important, AND > fast membership testing is a unique sales point. > > So please for best impressions: let us have a look at our code, where > we use the > dict.setdefault(key,[]).append() idiom, where it could be replaced to > a better effectivity with dict.setdefault(key,set()).add() > > If it is less than 60%, forget it. If it is more.... > > Harald -- http://mail.python.org/mailman/listinfo/python-list
