In article <4ca6bd15$0$11112$c3e8...@news.astraweb.com>, Steven D'Aprano <st...@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. alb...@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list