sequence multiplied by -1

Albert van der Horst albert at
Wed Oct 6 15:28:36 CEST 2010

In article <4ca6bd15$0$11112$c3e8da3 at>,
Steven D'Aprano  <steve at> 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.

>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
        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


Groetjes Albert

Economic growth -- being exponential -- ultimately falters.
albert at spe&ar& &=n

More information about the Python-list mailing list