Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed1a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <531d2551$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> <531d2551$0$29994$c3e8da3$5496439d@news.astraweb.com>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Mon, 10 Mar 2014 02:35:36 -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.7984.1394440586.18130.python-list@python.org>
Lines: 60
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:68127

On Sun, Mar 9, 2014 at 8:37 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 09 Mar 2014 17:42:42 -0600, Ian Kelly wrote:
>
>> On Sun, Mar 9, 2014 at 4:03 PM, Gregory Ewing
>> <greg.ewing@canterbury.ac.nz> wrote:
>
>>> Note that it says "when possible", not "if the implementation feels
>>> like it".
>>
>> That's quite vague, and not much stronger a guarantee than "maybe". It's
>> technically "possible" for this augmented assignment to be performed in
>> place:
>>
>> x = 12
>> x += 4
>>
>> But it's not done in-place, because ints are meant to be immutable.
>
> That's incorrect. Ints aren't merely "meant" to be immutable, which
> implies that's it's optional, they are defined by the language
> specification and the reference implementation as immutable. Any
> interpreter where ints are mutable *is not Python*.

That's true, but is beside the point, which is that "when possible" is
not very meaningful.

>> In any case, this means that whether the operation is actually performed
>> in-place is an implementation detail -- if not of the Python
>> implementation then at least of the class -- and not something the user
>> should take for granted.
>
> Whether += operates in place or not is part of the interface of the
> class, not the implementation.
>
> Would you say that whether list.append operates in place or creates a new
> list is an implementation detail? Whether str.upper() creates a new
> string or modifies the existing one in place?

Of course not.  list.append is documented as modifying the list.
str.upper is documented as returning a copy of the string.

> Mutability versus
> immutability is part of the interface, not implementation, not
> withstanding that somebody could create an alternative class with the
> opposite behaviour: a MutableStr, or ImmutableList.

If the in-place behavior of += is held to be part of the interface,
then we must accept that += is not polymorphic across mutable and
immutable types, which in my mind largely* defeats the purpose of
having it.  After all, there should be one -- and preferably only one
-- obvious way to do it.  If you want in-place concatenation, the
obvious way to do it is by calling extend.  If you want copy
concatenation, the obvious way to do it is with the + operator.  Why
then should not just mutable sequences but immutable sequences as well
even offer the += operator?

* The one exception I can think of is numpy, where there is no more
obvious way to do in-place addition, and in that context I would
consider the in-place behavior to be part of the interface.