Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder1.xlned.com!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <5320ebce$0$29994$c3e8da3$5496439d@news.astraweb.com>
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>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Wed, 12 Mar 2014 19:35:29 -0600
Subject: Re: Tuples and immutability
To: Python <python-list@python.org>
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.8118.1394674579.18130.python-list@python.org>
Lines: 77
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:68318

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]

>>> 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__'