Comparing values of counter in python 3.3

[rusi]

On Monday, December 16, 2013 8:10:57 AM UTC+5:30, Roy Smith wrote:
>  rusi  wrote:

> > On Monday, December 16, 2013 7:29:31 AM UTC+5:30, alex23 wrote:
> > > > # Need to compare values of counter and reject in function/routine in 
> > > > value in counter2 is higher then value in counter1 for a current key
> > >      [(k,Counter2[k]) for k in Counter2 - Counter1]
> > Why not just?
> > Counter2 - Counter1
> > And if you want to uncounterify it then
> > dict(Counter2 - Counter1)
> > > Counters are awesome.
> > Yes -- agreed. But 'counter' is a strange name -- after checking whether
> > 'bag' and 'multiset' are there in the library, I would not think to
> > check anything else.

> Bag and multiset are names only CS weenies would think to look for.  
> Counter is the name for the rest of us :-)

Weenie? WEENIE?!? Harrumph! Im offended!! <wink>

More seriously: One issue with all the new good stuff --
comprehensions, generator expressions, dict comprehensions etc is that
the motivations/explanations are all couched imperatively.

So
1.

[something(v) for v in lst]

is understood as
2.

newlst = []
for v in lst:
  newlst.append(something(v))

and so the comprehension is just a one-liner for the for-loop
[Witness Mark's comments earlier that the for loop is more readable]

If instead the comprenension is seen as a programmers equivalent of the
set theory expression

3.

{something(v) | v ∈ lst }  # if the unicode gods deign to allow!

then they would be more easily appreciated and used.

The extreme example of this is that the implementation of
comprehensions were and continue to be wrong because of variable
leakage because 1 is equivalenced to 2 rather than 3.

To come back to the topic: Counter suggesting DO-ing counting
whereas  bag/multiset suggests BE-ing with counts;
ie the one sounds imperative, the other declarative

(which of course may mean its a CS-weenie speaking!)