[Python-Dev] Real-world use of Counter (original) (raw)

Ethan Furman ethan at stoneleaf.us
Wed Nov 5 20:13:37 CET 2014

On 11/05/2014 10:56 AM, Raymond Hettinger wrote:

Please stop using the mailing lists as way to make an end-run around discussions on the tracker. http://bugs.python.org/issue22766

You said that without compelling, real-world use cases you don't like to make changes.

The tracker has a very limited audience, while the mailing lists have a much greater chance of reaching the users who may actually have the use-cases you would consider.

You call it an end-run, I call it research.

Also, as asked the question is a bit loaded. Effectively, it asks "has anyone ever been surprised by an exception raised by a duck-typed function or method"?

Actually, it's asking, "Most other duck-typed methods will still raise a TypeError, but these few don't. Has that ever been a problem for you?"

The in-place operations on counters are duck-typed. They are intended (by design) to work with ANY type that has an items() method. The exception raised if doesn't have on is an AttributeError saying that the operand needs to have an items() method.

It would still be duck-typed with a hasattr call on the second operand checking for the necessary method, a TypeError could just as easily state the problem is a missing items() method, and then those three [*] in-place methods would raise the same error as the 20(?) other Counter methods under similar conditions.

Please let this one die. It seems to have become your pet project even after I've made a decision and explained my rationale.

You indicated you might make a change with sufficient real-world use-cases, so I'm trying to find some. If none show up, I'll let the matter drop.

-- Ethan

[*] Amusingly enough, there are four overridden in-place methods: three raise an AttributeError, but one (&=) still raises a TypeError.

More information about the Python-Dev mailing list