Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #80278 > unrolled thread

Real-world use of Counter

Back to article view | Back to comp.lang.python

Contents

  Real-world use of Counter Ethan Furman <ethan@stoneleaf.us> - 2014-11-05 08:26 -0800
    Re: Real-world use of Counter Rustom Mody <rustompmody@gmail.com> - 2014-11-05 22:00 -0800
      Re: Real-world use of Counter Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-06 08:51 -0700
      Re: Real-world use of Counter Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-06 22:05 -0700

#80278 — Real-world use of Counter

I'm looking for real-world uses of collections.Counter, specifically to see if anyone has been surprised by, or had to 
spend extra-time debugging, issues with the in-place operators.

Background:

Most Python data types will cause a TypeError to be raised if unusable types are passed in:

--> {'a': 0}.update(5)
TypeError: 'int' object is not iterable

--> [1, 2, 3].extend(3.14)
TypeError: 'float' object is not iterable

--> from collections import Counter
--> Counter() + [1, 2, 3]
TypeError: unsupported operand type(s) for +: 'Counter' and 'list'

Most Counter in-place methods also behave this way:

--> c /= [1, 2, 3]
TypeError: unsupported operand type(s) for /=: 'Counter' and 'list'

However, in the case of a handful of Counter in-place methods (+=, -=, &=, and |=), this is what happens instead:

--> c = Counter()
--> c += [1, 2, 3]
AttributeError: 'list' object has no attribute 'items'

Even worse (in my opinion) is the case of an empty Counter `and`ed with an incompatible type:

--> c &= [1, 2, 3]
-->

No error is raised at all.

In order to avoid unnecessary code churn (the fix itself is quite simple), the maintainer of the collections module 
wants to know if anybody has actually been affected by these inconsistencies, and if so, whether it was a minor 
inconvenience, or a compelling use-case.

So, if this has bitten you, now is the time to speak up!  :)

--
~Ethan~

[toc] | [next] | [standalone]

#80315

On Wednesday, November 5, 2014 9:57:08 PM UTC+5:30, Ethan Furman wrote:
> In order to avoid unnecessary code churn (the fix itself is quite simple), the maintainer of the collections module 
> wants to know if anybody has actually been affected by these inconsistencies, and if so, whether it was a minor 
> inconvenience, or a compelling use-case.
> 
> So, if this has bitten you, now is the time to speak up!  :)


Not in direct answer to your specific question, but Counter generally.

In studying (somewhat theoretically) the general world of 
collection data structures we see
- sets  -- neither order nor repetition
- bags  -- no order, repetition significant
- lists -- both order and repetition

Sometimes 'bag' is called 'multiset'
However counter is a weird non-standard name that overloads
an already overloaded term -- 'Counter' has a very standard meaning in programming and in hardware design.

Yes changing the name is too code-churn causing.
But a synonym Bag (or multiset) for Counter would be a pleasant
addition for me.

Calling a bag as counter is inappropriate for an analogous reason
to why calling a dictionary as a 'hash' is inappropriate --
it confuses an implementation detail for fundamental semantics.

--------
PS. I probably wont participate in this discussion hereafter because off-net for 2 weeks

[toc] | [prev] | [next] | [standalone]

#80337

[Multipart message — attachments visible in raw view] — view raw

On Nov 6, 2014 1:06 AM, "Rustom Mody" <rustompmody@gmail.com> wrote:
> In studying (somewhat theoretically) the general world of
> collection data structures we see
> - sets  -- neither order nor repetition
> - bags  -- no order, repetition significant
> - lists -- both order and repetition
>
> Sometimes 'bag' is called 'multiset'
> However counter is a weird non-standard name that overloads
> an already overloaded term -- 'Counter' has a very standard meaning in
programming and in hardware design.

"Bag" is also nonstandard. Other nonstandard names for the same type
include list, heap, bunch, sample, weighted set, occurrence set and
fireset. Knuth uses multiset, so let's stick with that.

As for Counter already having meanings in CS, the Python Counter is
compatible with those.

> Calling a bag as counter is inappropriate for an analogous reason
> to why calling a dictionary as a 'hash' is inappropriate --
> it confuses an implementation detail for fundamental semantics.

I've never liked the term "bag". In addition to being nonstandard it's also
very nonintuitive. "Multiset" is fine, except that it implies the
collection is a type of set, which the Python Counter is not.

The name "Counter" describes the intended use case, not the implementation,
so I think it's fine.

[toc] | [prev] | [next] | [standalone]

#80348

[Multipart message — attachments visible in raw view] — view raw

On Nov 6, 2014 10:51 AM, "Ian Kelly" <ian.g.kelly@gmail.com> wrote:
>
> On Nov 6, 2014 1:06 AM, "Rustom Mody" <rustompmody@gmail.com> wrote:
> > Calling a bag as counter is inappropriate for an analogous reason
> > to why calling a dictionary as a 'hash' is inappropriate --
> > it confuses an implementation detail for fundamental semantics.
>
> I've never liked the term "bag". In addition to being nonstandard it's
also very nonintuitive. "Multiset" is fine, except that it implies the
collection is a type of set, which the Python Counter is not.

I was thinking about this today, and it seems to me that the Python Counter
is not really even a multiset.

* The size of a multiset would be the count of all the elements; the len of
a Counter is only the number of keys.
* The multiplicity of an element in a multiset is restricted to the natural
numbers; the count of an element in a Counter can be any integer, even
negative.
* In a Counter, a key with a count of 0 is a distinct state from a key not
being present at all; in the latter case the element is not in the Counter,
while in the former case it *is* in the Counter. These states are also
distinct for the purpose of equality.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web