This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients Joshua.Chin, ethan.furman, pitrou, r.david.murray, rhettinger
Date 2014-11-01.06:42:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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).
Date User Action Args
2014-11-01 06:42:44rhettingersetrecipients: + rhettinger, pitrou, r.david.murray, ethan.furman, Joshua.Chin
2014-11-01 06:42:44rhettingersetmessageid: <>
2014-11-01 06:42:44rhettingerlinkissue22766 messages
2014-11-01 06:42:44rhettingercreate