Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: Tuples and immutability
Date: Wed, 12 Mar 2014 22:09:24 -0400
References: <lennh4$kpm$1@cabale.usenet-fr.net> <CAPTjJmomgZSFj7TanBn8_qXP4ULhCm85abJ5=2PcikXJkrH6GQ@mail.gmail.com> <CAN1F8qU8AJ+Z-Rb4+wGsYWd_bS5aOA3bsjd5NjF46MUvnecSeQ@mail.gmail.com> <mailman.7473.1393598638.18130.python-list@python.org> <XnsA2E95FA1E1EB6duncanbooth@127.0.0.1> <bnvctpF5vanU1@mid.individual.net> <mailman.7920.1394252278.18130.python-list@python.org> <bo1rjpFll5mU1@mid.individual.net> <mailman.7944.1394332838.18130.python-list@python.org> <bo46qcF6dofU1@mid.individual.net> <mailman.7972.1394408612.18130.python-list@python.org> <bo7jo9Fsaf1U1@mid.individual.net> <mailman.8040.1394534428.18130.python-list@python.org> <531f3dfb$0$29994$c3e8da3$5496439d@news.astraweb.com> <mailman.8066.1394579251.18130.python-list@python.org> <5320ebce$0$29994$c3e8da3$5496439d@news.astraweb.com> <CALwzid=_y=DPujKZAqPvRqDSFGB7=zvbW=Egx+Y5F+gQ8UpCpQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
In-Reply-To: <CALwzid=_y=DPujKZAqPvRqDSFGB7=zvbW=Egx+Y5F+gQ8UpCpQ@mail.gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.8119.1394676599.18130.python-list@python.org>
Lines: 91
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:68319

On 3/12/2014 9:35 PM, Ian Kelly wrote:
> On Wed, Mar 12, 2014 at 5:20 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Tue, 11 Mar 2014 17:06:43 -0600, Ian Kelly wrote:
>>
>>> That's true but irrelevant to my point, which was to counter the
>>> assertion that mutable types can always be assumed to be able to perform
>>> operations in-place.
>>
>> "Always"? Not so fast.
>>
>> This is Python. We have freedom to abuse nearly everything, and if you
>> want to shoot yourself in the foot, you can. With the exception of a
>> handful of things which cannot be overridden (e.g. None, numeric
>> literals, syntax) you cannot strictly assume anything about anything.
>> Python does not enforce that iterators raise StopIteration when empty, or
>> that indexing beyond the boundaries of a sequence raises IndexError, or
>> that __setitem__ of a mapping sets the key and value, or that __len__
>> returns a length.
>
> Thank you; you've stated my point more succinctly than I did.
>
>> Augmented assignment is no different. The docs describe the intention of
>> the designers and the behaviour of the classes that they control, so with
>> standard built-in classes like int, str, list, tuple etc. you can safely
>> assume that mutable types will perform the operation in place and
>> immutable types won't, but with arbitrary types from some arbitrarily
>> eccentric or twisted programmer, who knows what it will do?
>
> This got me curious about how consistent the standard library is about
> this exactly, so I did some grepping.  In the standard library there
> are 5 mutable types that support concatenation that I was able to
> find: list, deque, array, bytearray, and Counter.  There are none that
> support addition, which I find interesting in that the language
> provides hooks for in-place addition but never uses them itself.
>
> All of the classes above appear to follow the rule that if you can
> concatenate an operand, you can in-place concatenate the same operand.
>   The converse however does not hold:  list.__iadd__ and
> Counter.__iadd__ are both more permissive in what types they will
> accept than their __add__ counterparts, and especially interesting to
> me is that deque implements __iadd__ but does not implement __add__ at
> all.  This last in particular seems to support the assertion that +=
> should be viewed more as a shorthand for an in-place operation, less
> as an equivalent for x = x + y.
>
>>>> l = [1,2,3]
>>>> l + (4,5,6)
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> TypeError: can only concatenate list (not "tuple") to list
>>>> l += (4,5,6)
>>>> l
> [1, 2, 3, 4, 5, 6]

Like it or not, one should actually think of 'somelist += iterable' as 
equivalent to 'somelist.extend(iterable)'.  Without looking at the C 
code, I  suspect that the latter is the internal implementation. 
Collections.deque also has .extend. Collections.Counter has .update and 
that is += seems to be doing.


>>>> c = collections.Counter('mississippi')
>>>> c + collections.Counter('alabama')
> Counter({'s': 4, 'a': 4, 'i': 4, 'p': 2, 'm': 2, 'b': 1, 'l': 1})
>>>> c + dict({'a': 4, 'l': 1, 'b': 1, 'm': 1})
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> TypeError: unsupported operand type(s) for +: 'Counter' and 'dict'
>>>> c += dict({'a': 4, 'l': 1, 'b': 1, 'm': 1})
>>>> c
> Counter({'s': 4, 'a': 4, 'i': 4, 'p': 2, 'm': 2, 'b': 1, 'l': 1})
>
>>>> d = collections.deque([1,2,3])
>>>> d += [4,5,6]
>>>> d
> deque([1, 2, 3, 4, 5, 6])
>>>> d + [7,8,9]
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> TypeError: unsupported operand type(s) for +: 'collections.deque' and 'list'
>>>> d.__add__
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> AttributeError: 'collections.deque' object has no attribute '__add__'
>


-- 
Terry Jan Reedy