a= ("x","y") b=["n","p"]
Сложить их не получилось
с=None c=a+b a=a+b b=a+b a+=b
b+=a
Пользуясь случаем сразу спрошу зачем существуют кортежи, в чем их преимущество перед списками? Знаю, что они неизменяемые, но можно ли это отнести к достоинствам?
Полная версия: Конкатенация кортежа к списку
Продолжаю разбираться с Python. В одном из самоучителей по нему прочитал, что можно складывать только однотипные данные. Речь шла о списках и кортежа. Столкнулся с таким поведением:
Сложить их не получилось
Но если сделать запись такого вида:
То она увенчается успехом и мы получим список. Это ожидаемое поведение? В чем здесь нюанс и отличие от b=b+a?
Пользуясь случаем сразу спрошу зачем существуют кортежи, в чем их преимущество перед списками? Знаю, что они неизменяемые, но можно ли это отнести к достоинствам?
Сложить их не получилось
Пользуясь случаем сразу спрошу зачем существуют кортежи, в чем их преимущество перед списками? Знаю, что они неизменяемые, но можно ли это отнести к достоинствам?
Похоже на баг.
Семантика bytearray() реализована теми же методами, но так не работает.
Так что можешь поискать описание чего-то подобного на https://bugs.python.org , просто вопрос там или вопрос с разъяснением. А может ты первый и нашёл это и обратил внимание.
Как-то непредсказуемо выглядит.
Семантика bytearray() реализована теми же методами, но так не работает.
>>> b = bytearray(b'abc') >>> b bytearray(b'abc') >>> b + [1, 2] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can't concat bytearray to list >>> b += [1, 2] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can't concat list to bytearray >>> b.extend([1, 2]) >>> b bytearray(b'abc\x01\x02') >>>
Так что можешь поискать описание чего-то подобного на https://bugs.python.org , просто вопрос там или вопрос с разъяснением. А может ты первый и нашёл это и обратил внимание.
Как-то непредсказуемо выглядит.
>>> lst = [1, 2, 3] >>> >>> lst + 'abc' Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can only concatenate list (not "str") to list >>> >>> lst += 'abc' >>> lst [1, 2, 3, 'a', 'b', 'c'] >>>
Эмм. Это никакой не баг 
Лучано Ромальо. Python. К вершинам мастерства.
Лучано Ромальо. Python. К вершинам мастерства.
> В чем здесь нюанс и отличие от b=b+a?
В том что ты в первом случае пытаешься изменить картеж.
> Пользуясь случаем сразу спрошу зачем существуют кортежи, в чем их преимущество перед списками?
В том что их нельзя изменять.
> Знаю, что они неизменяемые, но можно ли это отнести к достоинствам?
Конечно! ИХМО изменяемые объекты это зло.
В том что ты в первом случае пытаешься изменить картеж.
> Пользуясь случаем сразу спрошу зачем существуют кортежи, в чем их преимущество перед списками?
В том что их нельзя изменять.
> Знаю, что они неизменяемые, но можно ли это отнести к достоинствам?
Конечно! ИХМО изменяемые объекты это зло.
4kpt_VЭто нужно не в книжке смотреть, а в документации. Но тут и без документации понятно, что это поведение не одижаемо для пользователя.
Эмм. Это никакой не баг :)
Лучано Ромальо. Python. К вершинам мастерства.
И тут не работает аналог операции - значит, уже что-то не то.
lst = lst + 'abc' - не работает
lst += 'abc' - работает
То, что оно не ожидаемо, это еще не значит, что это баг. Это раз. В делфи вообще тьма тьмущая приведения типов. Просто, в пайтоне этого нет на базовых типах и мы привыкли
вот тут описано почему так происходит
вот тут описано почему так происходит
py.user.nextчето сомнения меня терзают по этому поводу.Поправте если я не прав.
Хотя вторая операция является сокращённой записью первой операции.
Что происходит когда вы делаете a + b?
Вызывается метод a.__add__(b)
если a.__add__ не определен то вызывается b. __radd__(a)
а когда a+=b то a.__iadd__(b)
логично предположить что в случае топикстартера методы .__add__ и __iadd__ работают по разному.
А вот баг это или фитча или особая, питонячая магия - ХЗ.
вдогонку
>>> a=[1,2,3] >>> id(a) 25782232 >>> a+=[4] >>> id(a) 25782232 >>> a= a+ [5] >>> id(a) 25767688 >>>
PEHDOM
Так и написано в топике, который я выше скинул. Вы правы. В одном случае происходит изменение объекта, а в другом создание нового. Но все равно поведение не очевидное и для питона это проблема. При этом мы не привыкли к неявному приведению типов. А тут такое…
Так и написано в топике, который я выше скинул. Вы правы. В одном случае происходит изменение объекта, а в другом создание нового. Но все равно поведение не очевидное и для питона это проблема. При этом мы не привыкли к неявному приведению типов. А тут такое…
4kpt_VТам описано другое
вот тут описано почему так происходит
Operator Overload, __and__, (+) and __iand__ (+=)
Both + and += operators are defined for list. They are semantically similar to extend.
my_list + another_list creates a third list in memory, so you can return the result of it, but it requires that the second iterable be a list.
my_list += another_list modifies the list in-place (it is the in-place operator, and lists are mutable objects, as we've seen) so it does not create a new list. It also works like extend, in that the second iterable can be any kind of iterable.
То есть он пишет только про списки. А то, что он пишет, что оно может быть любым итераблом в случае +=, ну, так он описал просто поведение этого бага. Это же не документация, иначе должно быть логическое обоснование, почему + не работает так же, а в документации на этот счёт ничего нет.
На списках оно работает.
lst = lst + [1, 2] - работает
lst += [1, 2] - работает
А на строках (кортежах и других итерабельных типах) не работает.
lst = lst + 'abc' - не работает
lst += 'abc' - работает
Это ошибка ядра питона. И, судя по поведению bytearray(), оно не должно работать со строками, потому что list() и bytarray() считаются подобными мутабельными типами.
Вот ещё итерабельный тип.
>>> lst = [1, 2, 3] >>> >>> lst + range(3) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can only concatenate list (not "range") to list >>> >>> lst += range(3) >>> >>> lst [1, 2, 3, 0, 1, 2] >>>
Да там просто вопрос был по list, поэтому человек и ответил про list. Был бы вопрос по tuple был бы тот же ответ. Это не бага. Это просто такая возможность. Типа как в последнем пайтоне словари, которые хранят последовательность. Просто возможность неявная, но это уже другое дело. Ну и все в документации написать не получиться никогда.