4 ms·

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 impli

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.

dasyatidprime 8y ago
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.
hjk05 8y ago
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.
- BerislavLopac 8y ago
  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.
  - glandium 8y ago
    In the context of strings, that's not true, and very commonly accepted: "a" + "b" == "ab" "b" + "a" == "ba"
    - BerislavLopac 8y ago
      Using + for string concatenation was an error introduced early in Python's design, and is to difficult to repair now.

dasyatidprime 8y ago

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.

hjk05 8y ago

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.

BerislavLopac 8y ago
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.
- glandium 8y ago
  In the context of strings, that's not true, and very commonly accepted: "a" + "b" == "ab" "b" + "a" == "ba"
  - BerislavLopac 8y ago
    Using + for string concatenation was an error introduced early in Python's design, and is to difficult to repair now.