Pre-PEP: Dictionary accumulator methods

Roose b at b.b
Tue Mar 22 05:14:28 CET 2005


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





More information about the Python-list mailing list