Python complaints

[Tim Peters]

[John Skaller]
> 	Integers are NOT objects in Python, they're values.
> Same for strings and tuples. We can pretend they're objects,
> and say they're 'immutable', but the truth is that they're
> just plain values.

The implementation doesn't support this view -- e.g., intobject.c has every
bit as much "object hair" as listobject.c.  There's no sense in which ints
are exempted from any of the general object machinery.  So it's unclear what
you're saying.  Perhaps that ints & strings etc don't support methods?
That's just historical accident, and in the current CVS snapshot most of the
string module's functionality has been reimplemented as methods of string
objects (very nice, btw! most <wink> people will like this).

> 	My new Viper interpreter may support 'mutable'
> integers and strings as follows: you write:
>
> 	x := 1
> 	x++
> 	x+=1
>
> This notation actually creates a reference (pointer) to the value,
> so x is a 'reference to an integer', and x++ actually means:
>
> 	x := x + 1
>
> To see the difference consider:
>
> 	a = 1
> 	x := a
> 	x++
> 	print a,x
>
> and you will get 1,2. The integer value a is bound to is still
> immutable and cannot be changed. x++, on the other hand,
> does not increment what x refers to, rather it replaces what
> x refers to by the old value plus 1.
>
> References in 'rvalue' contexts convert automatically to the
> designated value, but when used on the LHS the distinction
> between a reference to a value, and a value is preserved.
> [References can be used with any type, but they're not
> quite as useful with tuples (since there is a mutable list
> already) or with class instance objects (since they're
> already mutable).
>
> Comments on this idea appreciated.

I'm a long-time fan of augmented assignment (+= and friends), but prefer to
live without the pre- and post-increment gimmicks.  Introducing references
isn't necessary to implement the former, so unless you've got some other
killer use in mind for references I'd recommend not doing it that way (extra
syntax, extra complications, & mainline Python will likely never do it that
way).

If/when Guido adds augmented assignment to Python (he's not oppposed to it),

    thing += thang

will most likely compile to (pseudo-code):

    call thing.__addeq__(thang) # must return a result on the stack
    bind "thing" to the result in thing's namespace

It's then up to each object's __addeq__ method to decide whether to return
self (to effect a mutating +=) or to return a different object (to effect a
functional +=).  It's likely that int.__addeq__ will do the latter and
list.__addeq__ the former, so that

    x = 42
    y = x
    x += 1
    print x, y, x is y

prints

    43, 42, 0

while

    x = [1, 2, 3]
    y = x
    x += [4]
    print x, y, x is y

prints

    [1, 2, 3, 4], [1, 2, 3, 4], 1

when=-everything's-a-reference-nothing-isn't-ly y'rs  - tim