From: Steven D'Aprano on
On Sat, 01 May 2010 19:03:04 -0700, Chris Rebert wrote:

> On Sat, May 1, 2010 at 6:32 PM, Steven D'Aprano
> <steve(a)remove-this-cybersource.com.au> wrote:
>> On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote:
>>> This doesn't preclude you from implementing a self-mutating += style
>>> __add__ method and returning "self", but it's usually a bad idea
>>
>> Obviously the Python dev team don't agree with that :)
>>
>> Just to prove that += for lists is not an accident:
[...]
> In both cases, __iOP__ operator methods are being used, not vanilla
> __OP__ methods, so neither of your examples are relevant to Mr. Chase's
> point.


I'm sorry, I read Tim's reference to __add__ (instead of __iadd__) as a
typo. Having __add__ mutate self would be a strange thing to do.



--
Steven
From: Patrick Maupin on
On May 1, 9:03 pm, Chris Rebert <c...(a)rebertia.com> wrote:
> In both cases, __iOP__ operator methods are being used, not vanilla
> __OP__ methods, so neither of your examples are relevant to Mr.
> Chase's point.

Well, Tim's main assertion was: "The += family of operators really do
rebind the symbol, not modify the object."

So, using __iadd__ to disprove this blanket assertion is certainly
relevant.

Regards,
Pat


From: Aahz on
In article <4bdcd631$0$27782$c3e8da3(a)news.astraweb.com>,
Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> wrote:
>On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote:
>>
>> The += family of operators really do rebind the symbol, not modify the
>> object.
>
>They potentially do both, depending on the object, even for built-ins.

No, they always rebind; sometimes they modify the object and sometimes
they rebind the original target to the same object.
--
Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
From: Alf P. Steinbach on
On 02.05.2010 06:06, * Aahz:
> In article<4bdcd631$0$27782$c3e8da3(a)news.astraweb.com>,
> Steven D'Aprano<steve(a)REMOVE-THIS-cybersource.com.au> wrote:
>> On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote:
>>>
>>> The += family of operators really do rebind the symbol, not modify the
>>> object.
>>
>> They potentially do both, depending on the object, even for built-ins.
>
> No, they always rebind; sometimes they modify the object

If they always rebind and sometimes modify object then they "potentially do
both", and so the "No" at the start of the sentence contradicts this later part.


> and sometimes
> they rebind the original target to the same object.

At the Python level that seems to be an undetectable null-operation. Granted one
could see something going on in a machine code or byte code debugger. But making
that distinction (doing nothing versus self-assignment) at the Python level
seems, to me, to be meaningless.


Cheers,

- Alf
From: Chris Rebert on
On Sat, May 1, 2010 at 10:05 PM, Alf P. Steinbach <alfps(a)start.no> wrote:
> On 02.05.2010 06:06, * Aahz:
>> In article<4bdcd631$0$27782$c3e8da3(a)news.astraweb.com>,
>> Steven D'Aprano<steve(a)REMOVE-THIS-cybersource.com.au>  wrote:
>>>
>>> On Sat, 01 May 2010 07:13:42 -0500, Tim Chase wrote:
>>>>
>>>> The += family of operators really do rebind the symbol, not modify the
>>>> object.
>>>
>>> They potentially do both, depending on the object, even for built-ins.
>>
>> No, they always rebind; sometimes they modify the object
>
> If they always rebind and sometimes modify object then they "potentially do
> both", and so the "No" at the start of the sentence contradicts this later
> part.
>
>
>> and sometimes
>> they rebind the original target to the same object.
>
> At the Python level that seems to be an undetectable null-operation. Granted
> one could see something going on in a machine code or byte code debugger.
> But making that distinction (doing nothing versus self-assignment) at the
> Python level seems, to me, to be meaningless.

There are some circumstances where the subtle distinction matters.
Consider x.y += z where x is an instance of a class that overrides
__setattr__ and __getattribute__ and x.y results in a mutable object.
Not doing the assignment can result in a noticeable difference in
behavior since __setattr__ won't get called. Yes, this is a slightly
obscure case, but it does come up.

Cheers,
Chris
--
http://blog.rebertia.com