On Mon, 03 Nov 2014 10:53:09 +0000, Ethan Furman <report@bugs.python.org> wrote:
> 
> Ethan Furman added the comment:
> 
> > I don't want to change the kind of exception being raised (an API change from
> > AttributeError to TypeError) without a really good reason.
> 
> Subclasses cannot work with the current implementation.

I don't understand this statement.

> > Also, I prefer the current AttributeError with its clear indication that an items()
> > method is needed for duck-typing.  These kind of error messages are very helpful
> > when you're trying to figure-out how to duck-type on-purpose
> 
> That's what the docs are for.

That's not the way it works in real life.  You implement something, it
doesn't work, and if the solution isn't obvious from the error message
*then* you look at the docs or google.  But if the error message says
"you can't do this", then like as not you don't even look at the docs.

> > (for example, {}.update(1) and {}.update([[]]) both provide the information about
> > what you would need to do to get update() to work).
> 
> update is not a binary operation, so has more leeway in how it handles problems.

As Raymond pointed out, the augmented assignment operator is a
*shortcut* for update.

> > The current duck-typeable behavior was an intended part of the design and is no
> > different from a number of other methods that update in-place.
> 
> The only problem with the design is that it does not play well with others.  For duck-typeable just do a check on 'other' to see if it has an .items() method, and return NotImplemented if it does not.  Oh, and check that 'self' is Counter, and also return NotImplemented if that fails.

No, that doesn't support duck typing.  Duck typing is not putting
arbitrary restrictions on what objects you accept, but only essential
restrictions.  And as noted above, if you return NotImplemented, then
you get an error message that essentially says "this is impossible"
instead of "this is what didn't work".

> Here's proof of subclass trouble -- the idea is to make an immutable Counter:

Your subclass doesn't override __iadd__ or any of the other mutation
methods.  Why would you expect it to be immutable if it doesn't?

> For subclassing to work, the fix is:
> 
>         if not hasattr(other, 'items') or type(self) is not Counter:
>             return NotImplemented

I've never seen a type check like that in a Python class, and I hope
I never do.  *That* breaks subclassing.