Augmented Assignement (was: Re: PEP scepticism)

[Paul Prescod]

Skip Montanaro wrote:
> 
>     Paul> "Advanced" types could have "smart" behaviour and simple types
>     Paul> could have x=x+y behaviour.
> 
> Let's ignore lists, tuples and numbers for a moment because most people know
> how they are supposed to work (or will figure it out with a simple script).
> Suppose I see code like this
> 
>     import mumble
>     x = mumble.Mumble()
>     ...
>     x += 1
> 
> How am I supposed to know without digging around in the code or docs for the
> mumble module if it is a "simple" or "advanced" type?  

You won't know. But there is a lot you don't know about modules without
reading the docs. What this does:

print mumble

It could open a socket and download Quake for all you know.

> You haven't solved
> any problems, just added a new protocol for programmers to implement that
> will be done so in a haphazard fashion.

Making a problem so rare that very few people ever run into it is
progress.

The way I see it, 95% of all types will be non-mutating. The exceptions
will be types that are used primarily by speed freaks. I can't actually
recall the last third-party type that I've used that used serious
mathematical operator overloading. (obviously I'm not a Numpy user) 

The average user will simply not run into the issue, just as they don't
have to spend much effort worrying about whether "print" will do
something weird and wonderful. And yes, I've actually run into a
"__repr__" that opened a socket -- but it didn't download Quake. If we
can restrict the problem to math-type people then that's better than
confusing *everybody*. Especially since the math-type people asked for
the confusing behaviour.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook