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

[Chris Angelico]

On Wed, Oct 16, 2013 at 2:01 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Tue, 15 Oct 2013 19:57:50 +1100, Chris Angelico wrote:
>> Python doesn't happen to implement str-str or str/str, but some
>> languages do:
>
> Which languages are you talking about?
>
> For the record, if PHP is one of them, I consider that a good sign that
> it shouldn't be done :-)

My examples here are from Pike.

>>> "abc"+"def"-"abc";
>> (1) Result: "def"
>
> Eww. What would "xyz" - "abc" give? How about "cba" - "abc"?
>
> And "abcdabc" - "abc"?
>
> Justify your answers.

> "xyz" - "abc";
(1) Result: "xyz"
> "cba" - "abc";
(2) Result: "cba"
> "abcdabc" - "abc";
(3) Result: "d"

Every instance of the subtracted-out string is removed. It's something
like x.remove(y) in many other languages.

>>> "abc"-"b";
>> (2) Result: "ac"
>>> "foo bar asdf qwer"/" "*"##";
>> (3) Result: "foo##bar##asdf##qwer"
>
> And what, pray tell, would "foo bar" / " " be on its own?

A two-element array "foo","bar":

> "foo bar" / " ";
(4) Result: ({ /* 2 elements */
                "foo",
                "bar"
            })

> How about "foo bar" * "*"?

That's an error (the equivalent of TypeError).

> Seems to me that using s/t*u as a way to perform substring replacement is
> too clever by half.

Maybe :) It looks fancy for something like this. Normally, I use
string division with iteration, but there is a more direct "replace"
function for when that's being done.

> Personally, I think string and array concatenation ought to be & rather
> than +. That would free up + for element-wise addition for arrays, while
> still allowing & for concatenation. Of course, the cost would be the loss
> of an element-wise bit-and operator. You win some, you lose some.

I don't know who was first to implement string+string --> concat, but
since it's swept the world, it's worth keeping just on that basis, in
the same way that the use of octal for character escapes like "\123"
is worth keeping:

>>> ord("\123")
83
>>> 0o123
83

Confused me no end when I came across BIND's use of that syntax to
mean decimal. So if & has its problems and + has its problems, go with
+, as it'll confuse less people.

ChrisA