Pre-PEP: Dictionary accumulator methods

[haraldarminmassa at gmail.com]

Raymond,

I am +1 for both suggestions, tally and appendlist. 

Extended:
 
> Also, in all of my code base, I've not run across a single opportunity to use
> something like unionset().  This is surprising because I'm the set() author and
> frequently use set based algorithms.    Your example was a good one and I can
> also image a graph represented as a dictionary of sets.  Still, I don't mind
> writing out the plain Python for this one if it only comes up once in a blue
> moon.

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