Is behavior of += intentional for int?

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Sun Aug 30 14:37:38 EDT 2009


On Sun, 30 Aug 2009 12:04:45 -0500, Derek Martin wrote:

> On Sun, Aug 30, 2009 at 03:42:06AM -0700, Paul McGuire wrote:
>> Python binds values to names. Always.
> 
> No, actually, it doesn't.  It binds *objects* to names.  This
> distinction is subtle, but important, as it is the crux of why this is
> confusing to people.  If Python is to say that objects have values, then
> the object can not *be* the value that it has, because that is a
> paradoxical self-reference.  It's an object, not a value.

You're thinking about this too hard and tying yourself in knots trying to 
philosophise about it. In context of OO programming, the distinction 
between objects and values is fuzzy, and it depends on the context: e.g. 
if I have this:

class MyInt(int):
    pass

five = MyInt(5)
five.thingy = 23

is thingy part of the value of the object or not?

For most objects, at least for built-ins, the object *is* the value. (For 
custom classes you create yourself, you are free to do anything you 
like.) There's no need to try to distinguish between the object 3 and the 
value of the object 3: you're looking for a distinction that simply 
doesn't matter.


>> Is it any odder that 3 is an object than that the string literal
>> "Hello, World!" is an object?
> 
> Yes.  Because 3 is a fundamental bit of data that the hardware knows how
> to deal with, requiring no higher level abstractions for the programmer
> to use it (though certainly, a programming language can provide them, if
> it is convenient).  "Hello, World!" is not.  They are fundamentally
> different in that way.

Nonsense on two levels.

Firstly, in Python, *both* 3 and "Hello World" are complex objects, and 
neither are even close to the fundamental bits of data that the hardware 
can deal with.

Secondly, in low level languages, both are nothing but a sequence of 
bytes, and hardware knows how to deal with bytes regardless of whether 
they are interpreted by the human reader as 3 or "Hello World". The 
compiler might stop you from adding 2371 to "Hell" or "o Wor" but the 
hardware would be perfectly happy to do so if asked.



>> 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.
> 
> I'm sure that's the case.  But it's been explained to him before, and
> yet he still can't seem to comprehend that not everyone immediately gets
> this behavior, and that this is not without good reason.

Oh, it's obvious that not everybody gets this behaviour. I understand 
full well that it's different to some other languages, but not all, and 
so some people have their expectations violated.


> So, since it *has* been explained to him before, it's somewhat
> astonishing that he would reply to zaur's post, saying that the behavior
> zaur described would necessarily lead to the insane behavior that Steven
> described.  When he makes such statements, it's tantamount to calling
> the OP an idiot.

Given Python's programming model and implementation, the behaviour asked 
for *would* lead to the crazy behaviour I described.

(For the record, some early implementations of Fortran allowed the user 
to redefine literals like that, and I'm told that Lisp will do so too.)

So what Zaur presumably saw as a little tiny difference is in fact the 
tip of the iceberg of a fairly major difference. I don't know how smart 
he is, but I'd be willing to bet he hadn't thought through the full 
consequences of the behaviour he'd prefer, given Python's execution 
model. You could make a language that behaved as he wants, and I wouldn't 
be surprised if Java was it, but whatever it is, it isn't Python.


> I find that offensive, 

It's moments like this that I am reminded of a quote from Stephen Fry:

"You're offended? So f***ing what?"

Taking offense at an intellectual disagreement over the consequences of 
changes to a programming model is a good sign that you've got no rational 
argument to make and so have to resort to (real or pretend) outrage to 
win points.


> especially considering that
> Steven's post displayed an overwhelming lack of understanding of what
> the OP was trying to say.

I'm pretty sure I do understand what the OP was trying to say. He 
actually managed to communicate it very well. I think he expects to be 
able to do this:

>>> n = 1
>>> id(n)
123456
>>> n += 1
>>> assert n == 2
>>> id(n)
123456

Do you disagree? What do *you* think he wants?



-- 
Steven



More information about the Python-list mailing list