Hrvoje Niksic <[EMAIL PROTECTED]> wrote: > > The current implementation of += uses __add__ for addition and > __iadd__ for addition that may or may not be in-place. I'd like to > know the rationale for that design. >
Apart from the obvious short answer of being consistent (so you don't have to guess whether or not a+=b is going to do an assignment), I think the decision was partly to keep the implementation clean. Right now an inplace operation follows one of three patterns: load a value LOAD_FAST or LOAD_GLOBAL do the inplace operation (INPLACE_ADD etc) store the result (STORE_FAST or STORE_GLOBAL) or: compute an expression DUP_TOP LOAD_ATTR do the inplace operation ROT_TWO STORE_ATTR or: compute two expressions DUP_TOPX 2 BINARY_SUBSCR do the inplace operation ROT_THREE STORE_SUBSCR I'm not sure I've got all the patterns here, but we have at least three different cases with 0, 1, or 2 objects on the stack and at least 4 different store opcodes. If the inplace operation wasn't always going to store the result, then either we would need 4 times as many INPLACE_XXX opcodes, or it would have to do something messy to pop the right number of items off the stack and skip the following 1 or 2 instructions. I see from PEP203 that ROT_FOUR was added as part of the implementation, so I guess I must have missed at least one other bytecode pattern for augmented assignment (which turns out to be slice assignment with a stride). -- http://mail.python.org/mailman/listinfo/python-list