On Tue, Oct 15, 2013 at 6:48 PM, Antoon Pardon <antoon.par...@rece.vub.ac.be> wrote: > Op 15-10-13 01:11, Chris Angelico schreef: >> On Tue, Oct 15, 2013 at 6:18 AM, John Nagle <na...@animats.com> wrote: > >> >>> Operator "+" as concatenation for built-in arrays but addition >>> for NumPy arrays. >> >> ... NumPy definitely isn't part of the language. It's not even part of >> the standard library, it's fully third-party. > > That doesn't matter. Adding and concating are different operations and > their are types in which both occur rather naturally. So as a designer > of such a class you have to choose for which operation you use the > natural python operator and for which operation you have to do it > differently. NumPy is just an example that you can't escape this sort > of incompatibilities in python.
So what should "abc" + "def" result in, if addition is different from concatenation? No, adding strings should concatenate them. And other arithmetic operators make sense, too; Python doesn't happen to implement str-str or str/str, but some languages do: > "abc"+"def"-"abc"; (1) Result: "def" > "abc"-"b"; (2) Result: "ac" > "foo bar asdf qwer"/" "*"##"; (3) Result: "foo##bar##asdf##qwer" PHP has separate addition and concatenation operators, and it doesn't help anything (granted, the biggest problem is that every other language we work with uses + to concat strings, so it's an easy source of bugs); having multiple operators for "add the elements of these arrays" and "add these arrays together" is really orthogonal to the general issue of adding and concatenating needing different operators. But as Steven said, the way different types are free to react differently to the same operators is *GOOD* design in Python. Java doesn't let user-defined types override operators, so all those possibilities are closed. You can argue that it's poor design in NumPy (and people will argue the contrary position), but it's definitely not a flaw in Python-the-language. ChrisA -- https://mail.python.org/mailman/listinfo/python-list