Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder3.xlned.com!newsfeed.xs4all.nl!newsfeed2.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: <bnvctpF5vanU1@mid.individual.net>
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>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Fri, 7 Mar 2014 21:17:14 -0700
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.7920.1394252278.18130.python-list@python.org>
Lines: 35
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:68023

On Fri, Mar 7, 2014 at 7:17 PM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Here's another idea: If the __iadd__ method returns the
> same object, *and* the LHS doesn't have a __setitem__
> method, then do nothing instead of raising an exception.

Maybe it doesn't have a __setitem__ because the object that was
retrieved is computed rather than stored, and the result of the
__iadd__ will simply be discarded.  Somewhat contrived example:

class LessThanFilter:

    def __init__(self, the_list):
        self._the_list = the_list

    def __getitem__(self, bound):
        return [x for x in self._the_list if x < bound]


filter = LessThanFilter([10, 20, 30, 40, 50])
filter[25] += [15, 17, 23]

Should that last line not raise an exception?  The __iadd__ call will
return the same object, and the LHS doesn't have a __setitem__ method.

> I don't think that's a problem, because the use case
> being addressed is where the object performs in-place
> modification and always returns itself. Any object that
> doesn't return itself is not modifying in-place, even
> if the returned object happens to be equal to the
> original one.

I already mentioned this earlier in the thread, but a balanced binary
tree might implement += as node insertion and then return a different
object if the balancing causes the root node to change.