Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Thu, 02 Feb 2012 16:28:28 +0000
From: MRAB <python@mrabarnett.plus.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: copy on write
References: <mailman.4709.1326455724.27778.python-list@python.org> <4f101f45$0$29999$c3e8da3$5496439d@news.astraweb.com> <mailman.4712.1326457859.27778.python-list@python.org> <4f102bd0$0$29999$c3e8da3$5496439d@news.astraweb.com> <4F107AAF.5000600@stoneleaf.us> <20120202141812.649c31d832bb15bd899eb952@johnohagan.com> <CABicbJLKh1Ticp=EDPBWTwESTn5HkDQsopTCWrYH-hY6isOgxQ@mail.gmail.com> <mailman.5348.1328170324.27778.python-list@python.org> <4f2a5478$0$29895$c3e8da3$5496439d@news.astraweb.com> <87haz9o6a9.fsf@xemacs.org>
In-Reply-To: <87haz9o6a9.fsf@xemacs.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Reply-To: python-list@python.org
Newsgroups: comp.lang.python
Message-ID: <mailman.5362.1328200096.27778.python-list@python.org>
Lines: 62
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:19797

On 02/02/2012 10:53, Hrvoje Niksic wrote:
> Steven D'Aprano<steve+comp.lang.python@pearwood.info>  writes:
>
>>  Perhaps you are thinking that Python could determine ahead of time
>>  whether x[1] += y involved a list or a tuple, and not perform the
>>  finally assignment if x was a tuple. Well, maybe, but such an approach
>>  (if possible!) is fraught with danger and mysterious errors even
>>  harder to debug than the current situation. And besides, what should
>>  Python do about non-built-in types? There is no way in general to
>>  predict whether x[1] = something will succeed except to actually try
>>  it.
>
> An alternative approach is to simply not perform the final assignment if
> the in-place method is available on the contained object.  No prediction
> is needed to do it, because the contained object has to be examined
> anyway.  No prediction is needed, just don't.  Currently,
> lhs[ind] += rhs is implemented like this:
>
> item = lhs[ind]
> if hasattr(item, '__iadd__'):
>      lhs.__setitem__(ind, item.__iadd__(rhs))
> else:
>      lhs.__setitem__(ind, item + rhs)
> # (Note item assignment in both "if" branches.)
>
> It could, however, be implemented like this:
>
> item = lhs[ind]
> if hasattr(item, '__iadd__'):
>      item += rhs                  # no assignment, item supports in-place change
> else:
>      lhs.__setitem__(ind, lhs[ind] + rhs)
>
> This would raise the exact same exception in the tuple case, but without
> executing the in-place assignment.  On the other hand, some_list[ind] += 1
> would continue working exactly the same as it does now.
>
> In the same vein, in-place methods should not have a return value
> (i.e. they should return None), as per Python convention that functions
> called for side effect don't return values.
>
> The alternative behavior is unfortunately not backward-compatible (it
> ignores the return value of augmented methods), so I'm not seriously
> proposing it, but I believe it would have been a better implementation
> of augmented assignments than the current one.
 >
[snip]
Could it not perform the assignment if the reference returned by
__iadd__ is the same as the current reference?

For example:

     t[0] += x

would do:

     r = t[0].__iadd__(x)
     if t[0] is not r:
         t[0] = r

Should failed assignment be raising TypeError? Is it really a type
error?