
On Sat, Feb 14, 2015 at 5:30 PM, Steven D'Aprano <steve@pearwood.info> wrote:
On Sat, Feb 14, 2015 at 11:41:52AM -0800, Chris Barker wrote:
I have argued that this never would have come up if augmented assignment were only used for in-place operations,
And it would never happen if augmented assignment *never* was used for in-place operations.
Sure -- but then it would only be syntactic sugar, and mostly just for incrementing integers. I'm pretty sure when this was all added, there were two key use-cases: numpy wanted an operator for in=place operations, and lots of folks wanted an easy way to increment integers, etc. This was a way to kill two brids with one stone -- but resulted in good way for folks to get confused. Operator overloading fundamentally means that the definition of operators depends on the operands, but it's better if there isn't a totally different concept there as well. in-place operations and operating then-reassigning are conceptually very different. But that cat is out of the bag -- the question is: is there arw ay to limit the surprises -- can we either let "Mutating an object inside an immutable" work, or, at least, have it raise an exception before doing anything. Is suspect the answer to that is no, however :-( -Chris Alas, there's no way to enforce the rule that __iadd__ doesn't modify
objects in place,
sure -- though it could not do that for any built-in and be discouraged in the docs and PEP 8.
and it actually is a nice optimization when they can do so.
More than nice -- critical, and one of the original key use-cases. OH well. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov