Hacker News Reader

Comment by ehsankia | Hacker News Reader

I'm curious, why not override the usual + operator, which is far more idiomatic, instead of trying to get cute by using using an operating which generally implies division. Yes, it's fun once you understand it, but at a first look, it's more confusing than useful, whereas + would be fairly self explanatory.

View on HN

Well, / is path traversal; I think + would be too easily conflated with the “similar but importantly different” string concatenation, especially since « + "/" + » is an idiom in string-based path manipulation. For instance:

  p1 = "/a/b/c"
  x = "d"
  p1 + "/" + x == "/a/b/c/d"
  p2 = Path("/a/b/c")
  # If + replaced / for Path:
  p2 + "/" + x == Path("/d")

Now if you've just reflexively written the concatenation the way you did before, the type signatures match up but the result is completely wrong. The current situation where / doesn't exist for strings and + doesn't exist for Paths is much safer versus that.

You have a point, and I can’t tell you why they decided to go with /usr/bin/bash instead of usr+bin+bash back in the dawn of computing. I suppose you could write you own set of tools to change the entire ecosystem to use that convention, even providing new URL definitions.

But either way, I can’t see the problem with python defining the exact same operator to mean the exact same thing as you’d expect in that specific scenario.

The plus operator is traditionally expected to be symmetrical, i.e. a + b == b + a. The division operator, on the other hand, is not: a / b != b / a. The fact that a slash is used as a separator in paths is only a welcome coincidence.

In the context of strings, that's not true, and very commonly accepted:

"a" + "b" == "ab"

"b" + "a" == "ba"

Using + for string concatenation was an error introduced early in Python's design, and is to difficult to repair now.

Reply on news.ycombinator.com