Scope rule pecularities

[Antoon Pardon]

Op 2004-05-13, Andrew Bennetts schreef <andrew-pythonlist at puzzling.org>:
> On Thu, May 13, 2004 at 07:58:07AM +0000, Antoon Pardon wrote:
>> Op 2004-05-13, Greg Ewing schreef <greg at cosc.canterbury.ac.nz>:
> [...]
>> 
>> > Besides, the semantics are as consistent as anything
>> > else in Python, where the objects being operated on
>> > get to determine the meaning of just about everything.
>> 
>> So? Would you argue that the devellopers could just
>> as easily have implemented "a += b" as equivallent to
>> "a = a - b" with half of the core classes and called that
>> just as consistent as choosing it equivallent to
>> "a = a + b" for all core classes because the objects
>> being operated on get to determine the meaning?
>
> Well, classes get to do whatever they think makes sense: in the end it's all
> calls to methods of the object, whether via an actual method call
> "obj.foo()" or by an operator "obj * 2" (which calls obj.__mul__(2)) or an
> augmented assignment "obj += 'x'" (which calls obj.__iadd__('x')).  It's up
> to the objects to make sense, not the Python language.

And how do you think objects can make sense where the language doesn't?
I don't want to imply the language doesn't make sense at all, but you
can't claim the responsibility is all for the objects if the language
or its core classes have defiencies or are not consistent with each
other.

> Even though Python chooses to have some immutable builtin types (like
> ints and strings) for a variety of practical reasons, augmented assignment
> does what people expect in all these cases:
>
>     s = 'abc'
>     s += 'd'
>
>     i = 7
>     i += 3
>
>     l = [1, 2, 3]
>     l += [4, 5, 6]
>
> Augmented assignments are still assignments, and that makes perfect sense to
> me -- each of those behave exactly like their obvious longer versions:
>
>     s = 'abc'
>     s = s + 'd'
>
>     i = 7
>     i = i + 3
>
>     l = [1, 2, 3]
>     l = l + [4, 5, 6]
>
> (Yes, there are tricky examples that do behave differently -- but I try to
> avoid tricky things, because they tend to be hard to read.  I almost only
> find I want to use augmented assignment on integers and occasionally
> strings.)

But these things are only hard to read (to you, I don't find it so) because
you are using constants in the expression.

a += b, is just as hard to read whether a and b are lists or integers.

The problem is that because the behaviour with strings and lists is
different I can't write a program in which the behaviour of += is
consistent for all classes because there will always be core classes
for which the behaviour will be different.


It is a bit like having some classes use "+" for substraction. In it self
that wouldn't be so bad, you just have to pay attention. But then
you want to write a class that will work with whatever number type
and it needs to do additions. Now suddenly things get difficult because
a + b doesn't behave consistently among the different number types. 

You have the same kind of difficulty now if you want to write a
class/function/module that works with any kind of sequence.

Using the "+=" operator you can't guarantee any kind of consistency.
If I had code like this:

  a = b
  b += c

I would have no idea at all whether a was changed or not. So
writing code that can work with any sequence becomes a possible
problem spot if you use these kind of operators.

-- 
Antoon Pardon