Re: Counter Class -- Bag/Multiset

[msrachel . e]

On Jan 22, 5:41 pm, Giovanni Bajo  wrote:
> * I find it *very* confusing c.items() vs c.elements(). Items and
> elements are synonymous (again, in my understanding of English).

Would have used the term "items" but that term has a different meaning
in the context of dictionaries where "items" means (key,value) pairs.
The word "elements" is used for members of the set object and has a
parallel meaning in the context of multisets.  Since the class is a
dict subclass (as recommended by Guido), the term "items" was off
limits because it means something else.  So, "elements" as used in the
sets documentation was the next, natural choice.

Raymond
--
http://mail.python.org/mailman/listinfo/python-list

Re: Counter Class -- Bag/Multiset

[msrachel . e]

On Jan 22, 5:54 pm, Paul Rubin  wrote:
> Giovanni Bajo  writes:
> > * I'm not a native speaker, but why use the word "Counter"?
>
> I agree with this, the new functionality is welcome but I think
> the traditional term "multiset" or "bag" would have been better.

The term counter was what was originally approved.  At first, I didn't
like it but found that it had some advantages.  The main advantage is
that there are *bazillions* of programmers (including some very good
ones) who have never heard the term multiset or bag but have an
instant,
intuitive understanding of counting and counters.

Also, in the context of this implementation, "multiset" would not be a
good choice.  The mathematical entity, multiset, is defined with
elements
having a count of one or more.  In contrast, the Counter class allows
counts to go to zero or become negative.  In addition, I worried that
calling it a multiset would suggest that it has a set-like API instead
of a dict-like API.  With the former, you write c.add(elem).  With the
latter, you write c[elem] += 1.  So the name, "multiset" would be
misleading.

Bike-shed discussions aside (everyone has an opinion of how to name
things),
how do you guys like the functionality?  Do you find it useable in
real-world
use cases?

Raymond
--
http://mail.python.org/mailman/listinfo/python-list

Re: Counter Class -- Bag/Multiset

[msrachel . e]

On Jan 23, 12:27 am, bearophileh...@lycos.com wrote:
> bearophile:
>
> > Are keys restricted to be long and int values only? Or are they
> > general (referenced) objects + a control of their integral nature?
>
> Here I meant values, sorry.
> Also: what's the rationale of allowing negative values too?

The dict values can be anything, but only ints make sense in the
context of bags/multisets/counters etc.
Since it is a dict subclass, we really have no control of the
content.  It's pretty much a "consenting adults" data structure (much
like the heapq module which cannot enforce a heap condition on the
underlying list which is exposed to the user).

To block negative values, the setter methods would have to be
overridden and would dramatically slow down the major use cases for
counters (and we would not be able to let people freely convert to and
from arbitrary dicts).  Also, we would have to introduce and document
some kind of exception for attempts to set a negative value (i.e. c[x]
-= 1 could raise an exception).  This would unnecessarily complicate
the API in an attempt to limit what a user can do (perhaps barring
them from a use case they consider to be important).

So, if you don't want negative counts, I recommend that you don't
subtract more than you started off with ;-)

Raymond
--
http://mail.python.org/mailman/listinfo/python-list