On Oct 1, 9:38 pm, Steven D'Aprano <st...@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 -- http://mail.python.org/mailman/listinfo/python-list