Hacker News Reader

Comment by okasaki | Hacker News Reader

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.

View on HN

"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/Prelu...

> I'd be intrigued to hear someone's definition of the "reciprocal" of a path.

..

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/Prelu...

yeah but haskell would use ///

at least

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.

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.

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

Reply on news.ycombinator.com