counting occurrences

[Tim Peters]

[Grant Griffin, on a dict.items_sorted_by_reversed_value() method --
 or something of that ilk]

> I guess I wasn't really after "speed".  I was more interested in
> making this common operation more _accessible_ to beginners, and
> more _convenient_ to all

Things "like this" generally don't get in without a speed argument, though.
Like dict.update(f) is easy to program in Python, but significantly quicker
in C.  The other strike against it is "items_sorted_by_reversed_value":
that's only one of a dozen variations someone might want, and by the time
you have to import a module exposing "now which kind of sort + value and/or
key do you want?" symbolic constants, it's plain ugly.

Fear of that kind of bloat held up the introduction of dict.update() for
years:  in d.update(e), in case of duplicate keys k, most apps seem to want
e[k] to "win", but some want d[k] to triumph, others would prefer an
exception get raised, and still others want the new d[k] to be (d[k], e[k])
or [d[k], e[k]] or one of those swapped.  Guido was in a rare mood when he
said "oh, screw it -- e[k] wins".  You might be able to sell

    dict.sort()

picking one meaning on those (shaky) grounds.  Write a PEP, just for the
practice.

> --you know, kindda like list comprehensions.  (Or do we have LCs
> purely for "speed"<wink>?)

Speed actually was a listcomp argument, in that listcomps *could* be
significantly zippier than map applied to a lambda function.  In reality,
nobody has made time to speed up the implementation, but the potential is
still there.  About time you started hacking the Python core, Grant <wink>.

>> Note that in Python 2.2, you can *subclass* from dicts, like here in
>> grantdict.py:

> Great--thanks!  (Anything that uses _two_ list comprehensions in
> five lines can't be _all_ bad <wink>.)

Even better once you speed them up.

calling-you-to-greater-ambitions-ly y'rs  - tim