4 ms·

I'm not sure why it's wrong? Python isn't Haskell. If you're dealing with path manipulation a lot, it makes for much more readable code.

ehsankia 8y ago
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.
wodenokoto 8y ago
And if you are not dealing with this all the time, it makes the code completely unreadable.
jerf 8y ago
"Python isn't Haskell." Not sure exactly what you're saying there? Haskell strikes me as far more likely to define an operator for that. Although Haskell will define something other than /, which unless you jump through some hoops is going to be the fractional division operator [1]. You'd have to be crazy to try to give a "path" an instance of Fractional, though I'd be intrigued to hear someone's definition of the "reciprocal" of a path. [1]: https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#t:Fractional https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelu...
- twic 8y ago
  > I'd be intrigued to hear someone's definition of the "reciprocal" of a path. ..
  - jerf 8y ago
    Reciprocal is its own inverse, so the reciprocal of a/b/c and d/e/f can't both be "..". The closest you could come is an anti-path, where if you are at a/b/c, you could have c'/b'/a' that when combined together produced the root path of both these things. You could then have things like b'/a, which represents "rise up to the previous directory, which is named 'b', and descend into a" where the reciprocal is a'/b. I'm done fiddling with this for now, but it's possible you could work this into a sensible scheme with some concept of "reciprocal". It's useless in practice because who wants a .. operator that asserts the name of the directory it is rising from? (And presumably, what, errors if it isn't right? Refuses to rise like .. does at the root?) However since Fractional instances also have to be Num instances [1], and there's no practical way to fill in most of those, it's not going to get you very far. And the Fractional requirement of fromRational, while you can try to write something that turns a Rational (which in Haskell is specifically two Integers being used as a ratio) into a path, it's going to be very silly. [1]: https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#t:Fractional https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelu...
- agumonkey 8y ago
  yeah but haskell would use /// at least

ehsankia 8y ago

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.

wodenokoto 8y ago

And if you are not dealing with this all the time, it makes the code completely unreadable.

jerf 8y ago

"Python isn't Haskell." Not sure exactly what you're saying there? Haskell strikes me as far more likely to define an operator for that. Although Haskell will define something other than /, which unless you jump through some hoops is going to be the fractional division operator [1]. You'd have to be crazy to try to give a "path" an instance of Fractional, though I'd be intrigued to hear someone's definition of the "reciprocal" of a path. [1]: https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#t:Fractional https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelu...

twic 8y ago
> I'd be intrigued to hear someone's definition of the "reciprocal" of a path. ..
- jerf 8y ago
  Reciprocal is its own inverse, so the reciprocal of a/b/c and d/e/f can't both be "..". The closest you could come is an anti-path, where if you are at a/b/c, you could have c'/b'/a' that when combined together produced the root path of both these things. You could then have things like b'/a, which represents "rise up to the previous directory, which is named 'b', and descend into a" where the reciprocal is a'/b. I'm done fiddling with this for now, but it's possible you could work this into a sensible scheme with some concept of "reciprocal". It's useless in practice because who wants a .. operator that asserts the name of the directory it is rising from? (And presumably, what, errors if it isn't right? Refuses to rise like .. does at the root?) However since Fractional instances also have to be Num instances [1], and there's no practical way to fill in most of those, it's not going to get you very far. And the Fractional requirement of fromRational, while you can try to write something that turns a Rational (which in Haskell is specifically two Integers being used as a ratio) into a path, it's going to be very silly. [1]: https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#t:Fractional https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelu...
agumonkey 8y ago
yeah but haskell would use /// at least