Is behavior of += intentional for int?

[Derek Martin]

On Sat, Aug 29, 2009 at 07:03:23PM +0000, Steven D'Aprano wrote:
> On Sat, 29 Aug 2009 11:11:43 -0700, zaur wrote:
> 
> > I thought that int as object will stay the same object after += but with
> > another integer value. My intuition said me that int object which
> > represent integer value should behave this way.
> 
> If it did, then you would have this behaviour:

No, you wouldn't; the behavior you described is completely different
from, and incompatible with, what zaur wrote.  

He's saying that instead of thinking the integer value of 3 itself
being the object, he expected Python's object model would behave as
though the entity m is the object, and that object exists to contain
an integer value.  In that case, m is always m, but it has whatever
integer value it is told to hold at any point in time.  The
self-referential addition would access the value of m, add the
operand, and store the result back in the same object as the object's
value.  This is not the way Python works, but he's saying this is the
intuitive behavior.  I happen to agree, and argued at length with you
and others about that very thing months ago, when some other third
party posted with that exact same confusion.  

By contrast, your description maintains the concept of numerical value
as object that Python uses, and completely misses the point.  I did
find the description you gave to be highly enlightening though...  It
highlighted perfectly, I think, exactly why it is that Python's behavior
regarding numerical values as objects is *not* intuitive.  Of course,
intuition is highly subjective.

I believe it boils down to this:  People expect that objects they
create are mutable.  At least, unless they specify otherwise.  It is
so in some other programming languages which people may be likely to
be familiar with (if they are not taking their first forray into the
world of computing by learning Python), and even "real world" objects
are essentially always mutable.  If you have a 2002 Buick LeSabre, it
has a number of attributes, including its length, which might be 8.5
feet, for instance.  However, this is not fixed: by adding modified
body parts, or as an extreme example by sawing off the trunk of the
car, the length and indeed the object itself has been changed.
However, despite having been modified, it is at least in some sense
still the same object: it is still a 2002 Buick LeSabre, and it still
has the same *identity* (the same VIN number).  It's the same object,
but its value(s) changed.  [Not that it matters, but I do not own such
a car. :)]

Numbers are fundamentally different from objects.  The number 3 is a
symbol of the idea of the existence of three countable objects.  It
can not be changed (though it can be renamed, if you so choose -- just
don't expect most people to know what you're talking about).  It is
unintuitive that 3 is an object; it is rather what we use to describe
objects -- the value of the object.  It is an abstract concept, and
as such it is not an object at all.  You cannot hear 3, taste
3, nor smell 3.  You can neither see nor touch 3, though you can
certainly see 3 *objects* if they are present, and you can certainly
see the symbol '3' that we use to represent that idea... but you can
not see three itself, because there is no such object.  The only way
to see three is to envision 3 of some object.  The number 3 does not
have a value; it IS a value (it is the symbolic representation of the
value of three).  To say that 3 is an object that has a value is a bit
like saying the length of a car is an object that itself has a length.
It just doesn't compute.

THAT is why Python's behavior with regard to numerical objects is
not intuitive, and frankly bizzare to me, and I dare say to others who
find it so.

Yes, that's right.  BIZZARE.

Of course, none of this is real.  In the end, it's all just a bunch of
wires that either have current or don't.  It's only how *WE* organize
and think about that current that gives it any meaning.  So you're
free to think about it any way you like.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20090830/09105c4c/attachment.sig>