Raymond Hettinger added the comment:
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).
----------
resolution: -> not a bug
status: open -> closed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22766>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
