Sorry, I don't want to change the kind of exception being raised (an API change from AttributeError to TypeError) without a really good reason.

In general, in-place methods are not required to return NotImplemented (for example, (3).__iadd__(4.5) raises an AttributeError).

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 (for example, {}.update(1) and {}.update([[]]) both provide the information about what you would need to do to get update() to work).

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.

FWIW, I do recognize that in the specific case of "counter += 1" a TypeError is clearer than an AttributeError.  However, for duck-typeable methods, an AttributeError can sometimes be useful to indicate what is actually being required of the "other" argument (for example, Python 2 old-style classes raise an AttributeError with an informative message when calling an instance without a __call__ method or indexing an instance without a __getitem__ method).

At any rate, I want to avoid unnecessary API churn (and avoid contributing to what Guido has called "a death by a thousand cuts" for the growing list of tiny semantic differences between Python 2 and Python 3).