sequence multiplied by -1

[Carl Banks]

On Oct 1, 9:38 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> If so, then we haven't gained anything, and the only thing that would
> satisfy such people would be for every function name and operator to be
> unique -- something which is impossible in practice, even if it were
> desirable.

That is the ideal, yes, and no, it's not impossible.

I would be satisfied if operators were A) reserved for the most common
and useful operations, and B) should not be used for more than one
thing.

+ is the addition operator, which means it should be used for
addition, not concatenation.  & is a bitwise and operator, which means
it should only perform a bitwise and, not a set intersection.  And so
on.

The only reason ever to deliberately spell two things the same is
because those two operations can be usefully invoked polymorphicly by
the same code.  One can't write anything more than trivial code where
+ can be used both as addition and concatenation, therefore they
should not be spelled the same.  But one can easily write code where +
is useful as integer addition, floating point addition, and vector
addition.

Spelling things identically when they can't be used by the same code
hurts polymorphism.  For one, it attracts unwieldy attempts to use
polymorphism where it's not appropriate (sum).  Another thing that
hurts polymorphism is when two types have different ideas about which
way an operator should be used.  numpy arrays could usefully define
both concatenation and addition as separate operations, but since
Python uses the same operator for both, it can't.  As a result, + is a
completely different operation for lists and numpy arrays.  It would
be best for polymorphism if numpy arrays behave as much like lists as
possible (except where it's a deliberate enhancement, as with slicing)
but because Python chose to use + for something other than addition it
has to diverge.


Carl Banks