sequence multiplied by -1

[Antoon Pardon]

On Sat, Oct 02, 2010 at 05:03:17AM +0000, Steven D'Aprano 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.

I don't do that. I just find one particular language design choice unfortunatly
because the result is that some usefull function written in a general
way are less usefull than they could be.

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

Look I thought that python was supposed to be a usefull language. So
we expect that if a class has some general characteristics, we use
specific methods to implement those characteristics or behaviour,
so that we can write generic functions that depend on this abstraction.

All I'm pointing out is that by using the same name for the addition
operation and the concatenation operation, those two abstractions
can conflict with one another if you need a class that needs both
and I find that unfortunate.

Now if someone would start writing a class that would use .sort
as a method to do something completly different, I would have
the same complained about that. Because it would mean that should
I need a new class with characteristics both of this class and
of sortable sequences, that would be a problem too.


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

I would think that the number of operations is more of a factor than
the number of symbols used. I doubt that perl or APL would be that
much simpler if they somehow could manage all those different
operations by overloading more operations on the same symbols or names
 instead of using different symbols or names.

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

Well I think that concatenation and addition are two different kinds of
abstraction. Using the same symbols for both causes a problem when you
need a class that uses both abstractions, because you essentially loose
one of them.

-- 
Antoon Pardon