Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed1a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Return-Path: <ian.g.kelly@gmail.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.034
X-Spam-Evidence: '*H*': 0.93; '*S*': 0.00; 'suppose': 0.07; 'augmented': 0.09; 'immutable': 0.09; 'invalidate': 0.09; '*always*': 0.16; '*never*': 0.16; 'ancestor.': 0.16; 'equal.': 0.16; 'example?': 0.16; 'hierarchy': 0.16; 'in-place': 0.16; 'in- place,': 0.16; 'inheritance': 0.16; 'mutable': 0.16; 'preserving': 0.16; 'subclass': 0.16; 'wrote:': 0.18; 'example': 0.22; 'replace': 0.24; 'mon,': 0.24; 'solutions.': 0.26; 'header:In- Reply-To:1': 0.27; 'possibility': 0.29; 'message- id:@mail.gmail.com': 0.30; 'class': 0.32; 'quite': 0.32; 'not.': 0.33; 'updated': 0.34; "can't": 0.35; 'problem.': 0.35; 'objects': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'method': 0.36; 'possible': 0.36; 'changing': 0.37; 'to:addr :python-list': 0.38; 'pm,': 0.38; 'rather': 0.38; 'to:addr:python.org': 0.39; 'length': 0.61; 'new': 0.61; 'situation': 0.65; 'here': 0.66; 'mar': 0.68; 'natural': 0.68; 'circle': 0.68; 'late.': 0.68; 'obvious': 0.74; 'other.': 0.75; 'briefly,': 0.84; 'stretch': 0.91; 'remember,': 0.93
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=lmU7jTbaSbUp1h+3yGfAQSsqyItn3c+ck9N8F8p1+4M=; b=nXuKDM4QNaqGyvv05ngtxbmJVKeAJJY5IbaAWiZYDWydaO7FKWiaVMD9qprvhn+q7L aeSMXt3Htq1pSMavh7fK54YzXIuXNf6j557N9cD0jPxdfYSWKedn0l8FfoSUX6idZY2r e+vaIosfyi3LJLW4ZLKoTjp356sfPlz9VUn2UeKXwoCEVj54ezECRmy5V5XjkukH9Yeo x7ujG5GghhvupHBxK3VhZdaqqB/SAmjU/VIdidXH+DG2jIBuBRBzB5c52AxNDPP0JDzq MkuSqClhYhSKnkQfuFhaWk4IO5oU8qWSudnK1H3CexTrMNUGKikt3q6z9paTPOxBr2ej u64w==
X-Received: by 10.68.235.6 with SMTP id ui6mr9782794pbc.45.1394534419423; Tue, 11 Mar 2014 03:40:19 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <bo7jo9Fsaf1U1@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> <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>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Tue, 11 Mar 2014 04:39:39 -0600
Subject: Re: Tuples and immutability
To: Python <python-list@python.org>
Content-Type: text/plain; charset=ISO-8859-1
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.8040.1394534428.18130.python-list@python.org>
Lines: 31
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1394534428 news.xs4all.nl 2917 [2001:888:2000:d::a6]:56439
X-Complaints-To: abuse@xs4all.nl
Xref: csiph.com comp.lang.python:68208

On Mon, Mar 10, 2014 at 11:03 PM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> As far as observable effects are concerned, it's
> quite clear: mutable objects can *always* be updated
> in-place, and immutable objects can *never* be.

Hm. Consider the circle-ellipse problem.  Briefly, a circle is-an
ellipse, so in an inheritance hierarchy it is natural to make Circle a
subclass of Ellipse.  Now suppose the Ellipse has a stretch method
that mutates the ellipse by changing the length of one of its axes
while preserving the other.  To avoid violating LSP, the Circle class
must support all the methods of its ancestor.  However it cannot,
because the stretch method would invalidate the invariant of the
Circle class that both of its axes must always be equal.

There are a number of possible solutions.  One possibility would be to
copy the Circle as an Ellipse and return the new object instead of
mutating it.  Then you have the situation where, given a mutable
object x that satisfies isinstance(x, Ellipse), the stretch method
*may* be able to update the object in-place, or it *may* not.

I can't think of a reasonable example that would replace the stretch
method here with an augmented assignment, but then it is rather late.

> It might be the obvious way for that particular operation on
> that particular type. But what about all the others?
> What's the obvious way to spell in-place set intersection,
> for example? (Quickly -- no peeking at the docs!)

You mean set.intersection_update?  The in-place set methods are not
hard to remember, because they all end in _update.