i can do
mylist+=mytuple but i cannot do
mylist=mylist+mytuple. why is that?
lt1/forums /home/forums 1> py3
Python 3.5.2 (default, Nov 23 2017, 16:37:01)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a=[1,2,3]
>>> b=(4,5,6)
>>> a+=b
>>> a=a+b
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "tuple") to list
>>>
lt1/forums /home/forums 1> py2
Python 2.7.12 (default, Dec 4 2017, 14:50:18)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a=[1,2,3]
>>> b=(4,5,6)
>>> a+=b
>>> a=a+b
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "tuple") to list
>>>
and mylist.extend(mytuple) also works.
One calls __add__ (+) the other __iadd__ (+=). The former creates a new list from concatination of two lists, the latter appends (i.e. in-place) items from an iterable, which is how extend works. Thus, the former is looking to combine lists, and the latter to extend with any viable iterable.
i assume __add__ came first, probably from GvR as part of the original design before the simplification of iterators. and __iadd__ came later, after the simplification of iterators and __add__ hasn't been updated, yet, to have consistency. maybe in Python4? maybe in some other implementation?
(Sep-27-2018, 08:27 PM)Skaperen Wrote: [ -> ]i assume __add__ came first, probably from GvR as part of the original design before the simplification of iterators. and __iadd__ came later, after the simplification of iterators and __add__ hasn't been updated, yet, to have consistency. maybe in Python4? maybe in some other implementation?
Er, huh? You can overide if you like. Seems consistent to me though. Changing the standard implementation of __add__ would cause a lot of problems I suspect.
seems inconsistent to me. define addition as you will, but there is no real reason for it to be different between + and +=. how it works in a named method is something else.
all the reasoning i keep reading about comes down to implementation and that's never a reason to limit a definition of how things should work, especially when something else shows that it can be done.
the __add__ method can be made to do what __iadd__ does, or simply just call __add__ to do it, by creating the new object, applying __iadd__ to that new object or by just doing what __iadd__ does, and returning that new object. since Python does not allow a retroactive method replacement for list, this cannot be "fixed" in Python code.
now here is where it gets fun. += works on tuples. treating a tuple as an iterator is easy enough. extending it is another thing. and += also works for strings.
my view that it is inconsistent is in reference to the effect as seen by use of the language, not by how it is implemented. if someone changed things so that both + and += supported concatenating a list on the left and a tuple on the right, then i would say it is consistent. what would you call it?
whatever is done for += should call __add__ for the implementation of the add step, regardless of the type or class. then it only takes a new class implementing __add__ and then both + and += will work. it should be like this for all operators that appending = makes them an "operate and assign". == is the only different case i can think of at the moment.
this also makes the language simpler. then it can be taught that by appending (only once) = to the operator, except for comparison operators (== >= <=), works like "do the first operator and assign to LHS".
You cannot implement __iadd__ for immutable types as in place changes are not supported. That is why the operator in question falls back to __add__ when handling such and therefore is merely syntactic sugar. Something to debate on the pydev mailing list if you want to debate further.
Hopefully the OP has the answer they needed appropriate to a homework question.
it wasn't homework. i don't do any homework. oh wait. i work at home (managing cloud setups ... like a virtual sysadmin). i don't have to work in the data center. so i just work at home.
post #1 was just one of my idiotic rants.