Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #18910 > unrolled thread

copy on write

Back to article view | Back to comp.lang.python

Contents

  copy on write Eduardo Suarez-Santana <esuarez@itccanarias.org> - 2012-01-13 11:33 +0000
    Re: copy on write Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-13 12:10 +0000
      Re: copy on write Chris Angelico <rosuav@gmail.com> - 2012-01-13 23:30 +1100
        Re: copy on write Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-13 13:04 +0000
          Re: copy on write Ethan Furman <ethan@stoneleaf.us> - 2012-01-13 10:40 -0800
            Re: copy on write 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-13 14:26 -0800
            Re: copy on write 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-13 14:26 -0800
          Re: copy on write John O'Hagan <research@johnohagan.com> - 2012-02-02 14:18 +1100
          Re: copy on write Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-02-02 01:34 -0500
          Re: copy on write John O'Hagan <research@johnohagan.com> - 2012-02-02 19:11 +1100
            Re: copy on write Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-02 09:16 +0000
              Re: copy on write Hrvoje Niksic <hniksic@xemacs.org> - 2012-02-02 11:53 +0100
                Re: copy on write MRAB <python@mrabarnett.plus.com> - 2012-02-02 16:28 +0000
                Re: copy on write Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-02-02 12:21 -0500
              Re: copy on write John O'Hagan <research@johnohagan.com> - 2012-02-03 01:17 +1100
              Re: copy on write Terry Reedy <tjreedy@udel.edu> - 2012-02-02 12:25 -0500
              Re: copy on write John O'Hagan <research@johnohagan.com> - 2012-02-03 14:08 +1100
                Re: copy on write Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-03 05:04 +0000
                  Re: copy on write Chris Angelico <rosuav@gmail.com> - 2012-02-03 16:28 +1100
                    Re: copy on write Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-03 07:35 -0800
                  Re: copy on write Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2012-02-03 10:08 +0100
                  Re: copy on write John O'Hagan <research@johnohagan.com> - 2012-02-03 21:47 +1100
                    Re: copy on write Wolfram Hinderer <wolfram.hinderer@googlemail.com> - 2012-02-05 06:09 -0800
                  Re: copy on write "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2012-02-03 16:15 +0000
        Re: copy on write Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-02-02 11:42 +0100
      Re: copy on write Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-01-13 08:50 -0500
        Re: copy on write Grant Edwards <invalid@invalid.invalid> - 2012-01-13 15:13 +0000
          Re: copy on write Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-01-13 11:48 -0500
            Re: copy on write Neil Cerutti <neilc@norwich.edu> - 2012-01-13 16:54 +0000
              Re: copy on write Grant Edwards <invalid@invalid.invalid> - 2012-01-13 18:15 +0000
                Re: copy on write Chris Angelico <rosuav@gmail.com> - 2012-01-14 05:26 +1100
                  Re: copy on write Grant Edwards <invalid@invalid.invalid> - 2012-01-13 19:30 +0000
                    Re: copy on write Neil Cerutti <neilc@norwich.edu> - 2012-01-13 20:11 +0000
              Re: copy on write Evan Driscoll <edriscoll@wisc.edu> - 2012-01-13 13:24 -0600
                Re: copy on write Neil Cerutti <neilc@norwich.edu> - 2012-01-13 21:20 +0000
                  Re: copy on write Evan Driscoll <edriscoll@wisc.edu> - 2012-01-13 16:48 -0600
                    Re: copy on write 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-02 05:33 -0800
                      Re: copy on write Evan Driscoll <edriscoll@wisc.edu> - 2012-02-02 15:20 -0600
                    Re: copy on write 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-02 05:33 -0800
                    Re: copy on write 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-03 14:16 -0800
                    Re: copy on write 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-03 14:16 -0800
            Re: copy on write Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-01 19:51 -0800
              Re: copy on write Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-02 05:31 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#19829

On 02/03/2012 06:04 AM, Steven D'Aprano wrote:
> Ultimately, there is no right answer, because the multitude of
> requirements are contradictory. No matter what Python did, somebody would
> complain.
Which makes me wonder why it was introduced at all, or at least so fast 
If you see the difference in speed in introducing augmented assignment 
vs how long it took to get conditional expression I start thinking of a 
bikeshed. In the first case we have something that raises semantic 
questions that are difficult to resolve, in the second case the 
semantics were clear, the big problem that delayed introduction was what 
syntax to use.

But the second took a lot longer to become part of the language than the 
first, which seems very odd to me.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#19831

On 03 Feb 2012 05:04:39 GMT
Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> On Fri, 03 Feb 2012 14:08:06 +1100, John O'Hagan wrote:
> 
> > I think we're 12 years late on this one. It's PEP 203 from 2000 and
> > the key phrase was:
> > 
> > "The in-place function should always return a new reference, either
> > to the old `x' object if the operation was indeed performed
> > in-place, or to a new object."
> > 
> > If this had read:
> > 
> > "The in-place function should return a reference to a new object if
> > the operation was not performed in-place."
> > 
> > or something like that, we wouldn't be discussing this.
> 
> And what should it return if the operation *is* performed in-place?


Not knowing anything about the inner workings of the interpreter, I'm agnostic on that as long as it's not "a new reference". Perhaps the old reference? 

[...snip undoubted reasons why returning None wouldn't work...]

I don't know what would work. Maybe it is insoluble. But didn't Hrvoje Niksic's post in this thread suggest it could have been implemented to work the way I'm saying, even supplying code to demonstrate it?

All I'm saying is that however it's implemented, x[i] += y should simply mutate x[i] in-place if x[i] implements that, otherwise it should do x[i] = x[i] + y. If I can say it under 25 words, surely it's implementable? (Whether it's practical to do so is another question.) 

The x[i] in x[i] += y can be seen as a reference to an object to be incremented rather than an assignment (despite the name). In that view, whether the name x[i] needs to be rebound to a new object, resulting in an assignment, depends on the capabilities of x[i], not x.

> 
> Yes, the current behaviour is a Gotcha, but it's a Gotcha that makes
> good sense compared to the alternatives.

I think it's worse than a Gotcha. IMHO a Gothcha is, for example, the mutable default arguments thing, which makes sense once you get it. This one has the bizarre consequence that what happens when you operate on an object depends on which name you use for the object. Not to mention that it succeeds after raising an exception.

> Ultimately, augmented assignment is *assignment*, just like it says
> on the tin. t[1] += x is syntactic sugar for t[1] = t[1].__iadd__(x).
> It can't and shouldn't fail to raise an exception if t is a tuple,
> because tuple item assignment *must* fail.

That makes sense if we view it strictly as assignment (but in that case the mutation of t[1] should not occur either).
But isn't it equally true if we say that z = t[1], then t[1] += x is syntactic sugar for z = z.__iadd__(x)? Why should that fail, if z can handle it?

[...]
> 
> Ultimately, there is no right answer, because the multitude of 
> requirements are contradictory. No matter what Python did, somebody
> would complain.
> 

Not complaining, just trying to contribute to the best of my ability. :)

John

[toc] | [prev] | [next] | [standalone]

#19930

On 3 Feb., 11:47, John O'Hagan <resea...@johnohagan.com> wrote:

> But isn't it equally true if we say that z = t[1], then t[1] += x is syntactic sugar for z = z.__iadd__(x)? Why should that fail, if z can handle it?

It's more like syntactic sugar for
y = t; z = y.__getitem__(1); z.__iadd__(x); y.__setitem__(1, z)

It's clear that only the last expression fails, after the mutation has
taken place.

Just in case you wonder about the y: you need it for more complicated
cases.
t[1][1] += [4] is syntactic sugar for
y = t.__getitem__(1); z = y.__getitem__(1); z.__iadd__([4]);
y.__setitem__(1, z)

That makes clear why there's no exception in this code:
>>> t = (0, [1, [2, 3]])
>>> t[1][1] += [4]
>>> t
(0, [1, [2, 3, 4]])

[toc] | [prev] | [next] | [standalone]

#19834

Steven D'Aprano wrote:

> Perhaps lists shouldn't define += at all, but then people will
> complain that mylist += another_list is slow. Telling them to use
> mylist.extend instead just makes them cranky. After all, mylist +
> another_list works, so why shouldn't += work?

    	It would work, it just wouldn't work in-place.

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
	--author unknown

[toc] | [prev] | [next] | [standalone]

#19784

Am 13.01.2012 13:30 schrieb Chris Angelico:

> It seems there's a distinct difference between a+=b (in-place
> addition/concatenation) and a=a+b (always rebinding),

There is indeed.

a = a + b is a = a.__add__(b), while

a += b is a = a.__iadd__(b).

__add__() is supposed to leave the original object intact and return a 
new one, while __iadd__() is free to modify (preference, to be done if 
possible) or return a new one.

A immutable object can only return a new one, and its __iadd__() 
behaviour is the same as __add__().

A mutable object, however, is free to and supposed to modify itself and 
then return self.


Thomas

[toc] | [prev] | [next] | [standalone]

#18917

On Fri, Jan 13, 2012 at 7:30 AM, Chris Angelico <rosuav@gmail.com> wrote:
> It seems there's a distinct difference between a+=b (in-place
> addition/concatenation) and a=a+b (always rebinding), which is sorely
> confusing to C programmers. But then, there's a lot about Python
> that's sorely confusing to C programmers.

I think this is confusing to just about everyone, when they first encounter it.

-- Devin

[toc] | [prev] | [next] | [standalone]

#18921

On 2012-01-13, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
> On Fri, Jan 13, 2012 at 7:30 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> It seems there's a distinct difference between a+=b (in-place
>> addition/concatenation) and a=a+b (always rebinding), which is sorely
>> confusing to C programmers. But then, there's a lot about Python
>> that's sorely confusing to C programmers.
>
> I think this is confusing to just about everyone, when they first
> encounter it.

That depends on what languages they've used in the past and whether
they skip reading any documentation and just assume that all languages
work the same way.

I would agree that for the majority of new users, they previously used
only languages where an assignment operator does a "copy value", and
that 90+ percent of the time those new users they assume all languages
work that way.

I'm not sure what we can do about that -- Python's semantics are well
documented.

-- 
Grant Edwards               grant.b.edwards        Yow! If our behavior is
                                  at               strict, we do not need fun!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#18925

On Fri, Jan 13, 2012 at 10:13 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2012-01-13, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
>> On Fri, Jan 13, 2012 at 7:30 AM, Chris Angelico <rosuav@gmail.com> wrote:
>>> It seems there's a distinct difference between a+=b (in-place
>>> addition/concatenation) and a=a+b (always rebinding), which is sorely
>>> confusing to C programmers. But then, there's a lot about Python
>>> that's sorely confusing to C programmers.
>>
>> I think this is confusing to just about everyone, when they first
>> encounter it.
>
> That depends on what languages they've used in the past and whether
> they skip reading any documentation and just assume that all languages
> work the same way.
>
> I would agree that for the majority of new users, they previously used
> only languages where an assignment operator does a "copy value", and
> that 90+ percent of the time those new users they assume all languages
> work that way.

That isn't what I was referring to. Specifically, it confuses almost
everyone the first time they encounter it that "a += b" is not the
same as "a = a + b".

And sure, it's documented. That's a bit of a cop-out though... it
isn't in the tutorial, and even if it were, it's not as if people
remember everything they read. It's not about whether you _can_ know
it as much as whether it is """obvious"". There's a bit of a feeling
that code should "do what it looks like" and be sort of understandable
without exactly understanding everything. Maybe this idea is wrong if
taken to an extreme (since it's really impossible to do completely),
but the feeling of it is probably decent. It's why we use "+" for
addition and "-" for subtraction, and not the other way around. You
don't need to know the details of operator overloading and
NotImplemented and so on to get what X + Y means for numbers, or even
for lists.

I feel like "a += b" is sort of implicitly understood by most
programmers to be the same as "a = a + b". If you asked someone what
it meant, their first answer would be "Oh, it means a = a + b"[*].
That is why it's confusing -- even to people that weren't already
exposed to that idea that these are equivalent, they get infected
fast. And then expectations get broken, because they're only *usually*
equivalent.

[*] Before posting this, I actually tried this on a Python IRC channel
-- and it happened exactly as so.

-- Devin

[toc] | [prev] | [next] | [standalone]

#18927

On 2012-01-13, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
> On Fri, Jan 13, 2012 at 10:13 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> On 2012-01-13, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
>>> On Fri, Jan 13, 2012 at 7:30 AM, Chris Angelico <rosuav@gmail.com> wrote:
>>>> It seems there's a distinct difference between a+=b (in-place
>>>> addition/concatenation) and a=a+b (always rebinding), which is sorely
>>>> confusing to C programmers. But then, there's a lot about Python
>>>> that's sorely confusing to C programmers.
>>>
>>> I think this is confusing to just about everyone, when they first
>>> encounter it.
>>
>> That depends on what languages they've used in the past and whether
>> they skip reading any documentation and just assume that all languages
>> work the same way.
>>
>> I would agree that for the majority of new users, they previously used
>> only languages where an assignment operator does a "copy value", and
>> that 90+ percent of the time those new users they assume all languages
>> work that way.
>
> That isn't what I was referring to. Specifically, it confuses
> almost everyone the first time they encounter it that "a += b"
> is not the same as "a = a + b".

If you've ever implemented operator=, operator+, and operator+=
in C++ you'll know how and why they are different. A C++
programmer would be wondering how either can work on immutable
objects, and that's where Python's magical rebinding semantics
come into play.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#18932

On 2012-01-13, Neil Cerutti <neilc@norwich.edu> wrote:

> If you've ever implemented operator=, operator+, and operator+=
> in C++ you'll know how and why they are different.

That assumes that C++ programmers understand C++.

;)

> A C++ programmer would be wondering how either can work on immutable
> objects, and that's where Python's magical rebinding semantics come
> into play.

-- 
Grant Edwards               grant.b.edwards        Yow! Thousands of days of
                                  at               civilians ... have produced
                              gmail.com            a ... feeling for the
                                                   aesthetic modules --

[toc] | [prev] | [next] | [standalone]

#18933

On Sat, Jan 14, 2012 at 5:15 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> That assumes that C++ programmers understand C++.

I understand C++ very well. That's why I use Python or Pike.

(With apologies to Larry Wall)

ChrisA

[toc] | [prev] | [next] | [standalone]

#18934

On 2012-01-13, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Jan 14, 2012 at 5:15 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> That assumes that C++ programmers understand C++.
>
> I understand C++ very well. That's why I use Python or Pike.
>
> (With apologies to Larry Wall)

Were one inclined to troll a bit, one might be tempted to claim that
using C++ is prima facie evidence of not understanding C++.

Not that I would ever claim something inflamitory like that...

-- 
Grant Edwards               grant.b.edwards        Yow! Thousands of days of
                                  at               civilians ... have produced
                              gmail.com            a ... feeling for the
                                                   aesthetic modules --

[toc] | [prev] | [next] | [standalone]

#18940

On 2012-01-13, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2012-01-13, Chris Angelico <rosuav@gmail.com> wrote:
>> On Sat, Jan 14, 2012 at 5:15 AM, Grant Edwards
>> <invalid@invalid.invalid> wrote:
>>> That assumes that C++ programmers understand C++.
>>
>> I understand C++ very well. That's why I use Python or Pike.
>>
>> (With apologies to Larry Wall)
>
> Were one inclined to troll a bit, one might be tempted to claim
> that using C++ is prima facie evidence of not understanding
> C++.
>
> Not that I would ever claim something inflamitory like that...

On the Python newsgroup, it's funny. ;)

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#18942

On 01/13/2012 10:54 AM, Neil Cerutti wrote:
> If you've ever implemented operator=, operator+, and operator+=
> in C++ you'll know how and why they are different.

At the same time, you'd also know that that implementing them in such a 
way that 'a += b' does *not* perform the same action as 'a = a + b' is 
considered very bad-mannered.

In fact, it's often suggested (e.g. in "More Effective C++"'s Item 22, 
though this is not the main thrust of that section) to implement 
operator+ in terms of += to ensure that this is the case:
  MyType operator+ (MyType left, MyType right) {
      MyType copy = left; copy += right; return copy;
  }

> A C++
> programmer would be wondering how either can work on immutable
> objects, and that's where Python's magical rebinding semantics
> come into play.

IMO a C++ programmer wouldn't be likely to wonder that much at all 
because he or she wouldn't view the objects as immutable to begin with. 
:-) 'x = 5; x += 1;' makes perfect sense in C++, just for a somewhat 
different reason.

Evan

[toc] | [prev] | [next] | [standalone]

#18948

On 2012-01-13, Evan Driscoll <edriscoll@wisc.edu> wrote:
> On 01/13/2012 10:54 AM, Neil Cerutti wrote:
>> If you've ever implemented operator=, operator+, and operator+=
>> in C++ you'll know how and why they are different.
>
> At the same time, you'd also know that that implementing them
> in such a way that 'a += b' does *not* perform the same action
> as 'a = a + b' is considered very bad-mannered.
>
> In fact, it's often suggested (e.g. in "More Effective C++"'s Item 22, 
> though this is not the main thrust of that section) to implement 
> operator+ in terms of += to ensure that this is the case:
>   MyType operator+ (MyType left, MyType right) {
>       MyType copy = left; copy += right; return copy;
>   }

They perform the same action, but their semantics are different.
operator+ will always return a new object, thanks to its
signature, and operator+= shall never do so. That's the main
difference I was getting at.

>> A C++ programmer would be wondering how either can work on
>> immutable objects, and that's where Python's magical rebinding
>> semantics come into play.
>
> IMO a C++ programmer wouldn't be likely to wonder that much at
> all because he or she wouldn't view the objects as immutable to
> begin with. :-) 'x = 5; x += 1;' makes perfect sense in C++,
> just for a somewhat different reason.

I was thinking of const objects, but you are correct that
immutable isn't really a C++ concept.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#18952

On 01/13/2012 03:20 PM, Neil Cerutti wrote:
> They perform the same action, but their semantics are different.
> operator+ will always return a new object, thanks to its
> signature, and operator+= shall never do so. That's the main
> difference I was getting at.

I was talking about the combination of + and =, since the discussion is 
about 'a = a + b' vs 'a += b', not 'a + b' vs 'a += b' (where the 
differences are obvious).

And I stand by my statement. In 'a = a + b', operator+ obviously returns 
a new object, but operator= should then go and assign the result to and 
return a reference to 'a', just like how 'a += b' will return a 
reference to 'a'.

If you're working in C++ and overload your operators so that 'a += b' 
and 'a = a + b' have different observable behaviors (besides perhaps 
time), then either your implementation is buggy or your design is very 
bad-mannered.

Evan

[toc] | [prev] | [next] | [standalone]

#19789

在 2012年1月14日星期六UTC+8上午6时48分29秒，Evan Driscoll写道：
> On 01/13/2012 03:20 PM, Neil Cerutti wrote:
> > They perform the same action, but their semantics are different.
> > operator+ will always return a new object, thanks to its
> > signature, and operator+= shall never do so. That's the main
> > difference I was getting at.
> 
> I was talking about the combination of + and =, since the discussion is 
> about 'a = a + b' vs 'a += b', not 'a + b' vs 'a += b' (where the 
> differences are obvious).
> 
> And I stand by my statement. In 'a = a + b', operator+ obviously returns 
> a new object, but operator= should then go and assign the result to and 
> return a reference to 'a', just like how 'a += b' will return a 
> reference to 'a'.
>

The operation a+b means add(a,b) and returns a result instance, furthermore a and b can't be modified.

The expression a = a+b are two operations not one. But in C or C++ the  problem is mixing operations and expressions in a free style allowed.
 
The operation a+=b means a modified by b and b can't be changed.
Note that no new instance is necessary in a+=b.
 
 

> If you're working in C++ and overload your operators so that 'a += b' 
> and 'a = a + b' have different observable behaviors (besides perhaps 
> time), then either your implementation is buggy or your design is very 
> bad-mannered.
> 
> Evan

Do you mean the result instances after 'a+=b' and 'a=a+b' or 
the actions of behaviors of instances involved  in performing 'a+=b' and 'a=a+b'?

[toc] | [prev] | [next] | [standalone]

#19811

On 01/-10/-28163 01:59 PM, 88888 Dihedral wrote:
>> If you're working in C++ and overload your operators so that 'a +='
>> and 'a = + b' have different observable behaviors (besides perhaps
>> time), then either your implementation is buggy or your design is very
>> bad-mannered.
>>
>> Evan
>
> Do you mean the result instances after 'a+= and 'a=a+b' or
> the actions of behaviors of instances involved  in performing 'a+= and 'a=a+b'?
>

I mean "if which operation you called is distinguishable in any way 
besides the time it takes to run or by tracing it through in a debugger"

That means:

1. The value of 'a' should be the same after executing 'a+=b' and
    'a=a+b'
2. The actual result of the expression should be the same in both cases
    (in both cases it should be a reference to a)
3. Any additional side effects performed (ew!) should be the same in
    both cases

Evan

[toc] | [prev] | [next] | [standalone]

#19790

在 2012年1月14日星期六UTC+8上午6时48分29秒，Evan Driscoll写道：
> On 01/13/2012 03:20 PM, Neil Cerutti wrote:
> > They perform the same action, but their semantics are different.
> > operator+ will always return a new object, thanks to its
> > signature, and operator+= shall never do so. That's the main
> > difference I was getting at.
> 
> I was talking about the combination of + and =, since the discussion is 
> about 'a = a + b' vs 'a += b', not 'a + b' vs 'a += b' (where the 
> differences are obvious).
> 
> And I stand by my statement. In 'a = a + b', operator+ obviously returns 
> a new object, but operator= should then go and assign the result to and 
> return a reference to 'a', just like how 'a += b' will return a 
> reference to 'a'.
>

The operation a+b means add(a,b) and returns a result instance, furthermore a and b can't be modified.

The expression a = a+b are two operations not one. But in C or C++ the  problem is mixing operations and expressions in a free style allowed.
 
The operation a+=b means a modified by b and b can't be changed.
Note that no new instance is necessary in a+=b.
 
 

> If you're working in C++ and overload your operators so that 'a += b' 
> and 'a = a + b' have different observable behaviors (besides perhaps 
> time), then either your implementation is buggy or your design is very 
> bad-mannered.
> 
> Evan

Do you mean the result instances after 'a+=b' and 'a=a+b' or 
the actions of behaviors of instances involved  in performing 'a+=b' and 'a=a+b'?

[toc] | [prev] | [next] | [standalone]

#19846

在 2012年1月14日星期六UTC+8上午6时48分29秒，Evan Driscoll写道：
> On 01/13/2012 03:20 PM, Neil Cerutti wrote:
> > They perform the same action, but their semantics are different.
> > operator+ will always return a new object, thanks to its
> > signature, and operator+= shall never do so. That's the main
> > difference I was getting at.

Well, in any associative operation with an identity implemented in a computer language  personally I believe the operator overloading part in C++ is   another teasing trick.

 
Do we have to work out the algebra here?

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web