Is behavior of += intentional for int?

[Paul McGuire]

On Aug 30, 2:33 am, Derek Martin <c... at pizzashack.org> wrote:
> 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.
>

Can't we all just get along?

I think the question boils down to "where is the object?".  In this
statement:

a = 3

which is the object, a or 3?

There exist languages (such as C++) that allow you to override the '='
assignment as a class operator.  So that I could create a class where
I decided that assigning an integer value to it applies some
application logic, probably the setting of some fundamental
attribute.  In that language, 'a' is the object, and 3 is a value
being assigned to it.  This can cause some consternation when a reader
(or worse, maintainer) isn't familiar with my code, sees this simple
assignment, and figures that they can use 'a' elsewhere as a simple
integer, with some surprising or disturbing results.

Python just doesn't work that way.

Python binds values to names. Always. In Python, "=" is not and never
could be a class operator.  In Python, any expression of LHS = RHS,
LHS is always a name, and in this statement it is being bound to some
object found by evaluating the right hand side, RHS.

The bit of confusion here is that the in-place operators like +=, -=,
etc. are something of a misnomer - obviously a *name* can't be
incremented or decremented (unlike a pointer in C or C++).  One has to
see that these are really shortcuts for LHS = LHS + RHS, and once
again, our LHS is just a name getting bound to the result of LHS +
RHS.  Is this confusing, or non-intuitive? Maybe. Do you want to write
code in Python? Get used to it.  It is surprising how many times we
think things are "intuitive" when we really mean they are "familiar".
For long-time C and Java developers, it is intuitive that variables
are memory locations, and switching to Python's name model for them is
non-intuitive.

As for your quibble about "3 is not an object", I'm afraid that may be
your own personal set of blinders.  Integer constants as objects is
not unique to Python, you can see it in other languages - Smalltalk
and Ruby are two that I know personally.  Ruby implements a loop using
this interesting notation:

3.times do
   ...do something...
end

Of course, it is a core idiom of the language, and if I adopted Ruby,
I would adopt its idioms and object model.

Is it any odder that 3 is an object than that the string literal
"Hello, World!" is an object?  Perhaps we are just not reminded of it
so often, because Python's int class defines no methods that are not
"__" special methods (type in "dir(3)" at the Python prompt).  So we
never see any Python code referencing a numeric literal and
immediately calling a method on it, as in Ruby's simple loop
construct.  But we do see methods implemented on str like split(), and
so "about above across after against".split() gives me a list of the
English prepositions that begin with "a". We see this kind of thing
often enough, we get accustomed to the objectness of string literals.
It gets to be so familiar, it eventually seems "intuitive".  You
yourself mentioned that intuition is subjective - unfortunately, the
"intuitiveness" of a feature is often tied to its value as a coding
concept, and so statements of non-intuitiveness can be interpreted as
a slant against the virtue of that concept, or even against the
language itself.

Once we accept that 3 is an object, we clearly have to stipulate that
there can be no changes allowed to it.  3 must *always* have the value
of the integer between 2 and 4.  So our language invokes the concept
that some classes create instances that are immutable.

For a Python long-timer like Mr. D'Aprano, I don't think he even
consciously thinks about this kind of thing any more; his intuition
has aligned with the Python stars, so he extrapolates from the OP's
suggestion to the resulting aberrant behavior, as he posted it.

You can dispute and rail at this core language concept if you like,
but I think the more entrenched you become in the position that "'3 is
an object' is bizarre", the less enjoyable your Python work will be.

-- Paul