Python was designed (was Re: Multi-threading in Python vs Java)

Chris Angelico rosuav at gmail.com
Tue Oct 15 04:57:50 EDT 2013


On Tue, Oct 15, 2013 at 6:48 PM, Antoon Pardon
<antoon.pardon at 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 <nagle at 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



More information about the Python-list mailing list