sequence multiplied by -1

[Albert van der Horst]

In article <4ca6bd15$0$11112$c3e8da3 at news.astraweb.com>,
Steven D'Aprano  <steve at REMOVE-THIS-cybersource.com.au> wrote:
>On Fri, 01 Oct 2010 14:56:52 +0200, Antoon Pardon wrote:
>
>> Think about the following possibility.
>>
>> Someone provides you with a library of functions that act on sequences.
>> They rely on the fact that '+' concatenates.
>>
>> Someone else provides you with a library of functions that act on
>> numbers. They rely on the fact that '+' provides addition.
>>
>> Now however you write your sequence like numbers or number like
>> sequences one of those libraries will be useless for it.
>
>And? So what? Sequences aren't numbers. Numbers aren't sequences. You
>can't expect every library to correctly work with every data type
>regardless of the polymorphism of operators.
>
>If you have no idea what x is, you can't possibly expect to know what
>function(x) does, *for any function*.
>
>(Actually, there may be one or two exceptions, like id(x). But fewer than
>you think -- even str(x) is not guaranteed to work for arbitrary types.)
>
>If you don't know whether x is a number or a sequence, you can't know
>what x.sort() will do, or math.sqrt(x), or x+x. Why single out x+x as
>more disturbing than the other examples?
>
>
>>> -- which would it do with only one
>>> symbol?
>>
>> But why limit ourselves to one symbol for different kind of operations,
>> to begin with?
>
>Because the more symbols you have, the higher the learning curve to
>become proficient in the language, and the more like line-noise the code
>becomes. If you want APL or Perl, you know where to find them -- they're
>perfectly reasonable languages, but they have made design choices that
>are not Python's design choices.
>
>We use operators, because for certain common operations it is more
>convenient and natural to use infix notation than function notation. And
>polymorphism is useful, because it reduces the size of namespaces and
>therefore the burden on the programmer. Putting these two factors
>together, instead of:

There is one more important argument.
Suppose + on a certain type of a objects generates the same type
of object.
Suppose (x+y)+z = x+(y+z) (always)
This is called associativity.

Then we can forget about the brackets.
A simple expression like
        y = [1,2,3] + x + [4,5,6] + z
becomes a mess without leaning on this associativity law.

Note that concatenation is by nature associative. It is so natural
that you almost must be a mathematician to realize that.

>
>concat_lists
>concat_tuples
>concat_strings
>concat_bytes
>add_floats
>add_ints
>add_rationals
>add_decimals
>
>plus mixed-operand versions of at least some of them, we have a single
>symbol, +, for all of these. Arguing about whether it should be a single
>operator + or two operators + & is a comparatively trivial matter. I
>believe that the similarity between concatenation and addition is close
>enough that it is appropriate to use one symbol for both, and likewise
>between repetition and multiplication. I'm glad that Guido apparently
>agrees with me.

The important thing is that manipulations are the same such
that
        a += b
        a += c
        a += d
can be replaced by
        a = b + c + d
without much thought to what a b c and + represent.
In other words reuse of the important brain resource of pattern
recognition.

>--
>Steven

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert at spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst