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.
If sufficient and/or compelling use-cases are uncovered, the behavior of
Counter may be slightly modified.
On 2014-11-05 16:33, Ethan Furman wrote:
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.
If sufficient and/or compelling use-cases are uncovered, the behavior
On Nov 5, 2014, at 8:33 AM, Ethan Furman et...@stoneleaf.us wrote:
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.
Please stop using the mailing lists as
On 11/05/2014 10:09 AM, MRAB wrote:
On 2014-11-05 16:33, Ethan Furman wrote:
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.
The final example, however, is odd. I think that one should be fixed.
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
On Wed, 05 Nov 2014 11:13:37 -0800, Ethan Furman et...@stoneleaf.us wrote:
On 11/05/2014 10:56 AM, Raymond Hettinger wrote:
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
Ethan Furman wrote:
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?
I don't think I've *ever* been bothered by getting an
AttributeError instead of a TypeError or vice versa.
Both indicate bugs in my
On Wed, Nov 5, 2014 at 2:47 PM, R. David Murray rdmur...@bitdance.com
wrote:
As I said on the issue, there is no reason I can see to add extra code
just to turn an AttributeError into a TypeError. The AttributeError
works just fine in letting you know your input type didn't work.
+1
Unlike
