4 ms·

You're not alone. My goto example of this is the pathlib module added in 3.4. It has this feature for making it easier to concat strings representing file syste

You're not alone. My goto example of this is the pathlib module added in 3.4. It has this feature for making it easier to concat strings representing file system paths... >>> from pathlib import Path >>> Path("foo/bar") / "baz" PosixPath('foo/bar/baz') Don't get me wrong, the existing solutions until pathlib (os.path.join or string concatenation) left a lot to be desired. And there are certain tricky path-parsing things this module does that are wonderful. But overloading the __div__ operator for a "cute" API just feels... wrong... Of course, after my initial disgust, I now use it everywhere :)

masklinn 7y ago
Note that you don't have to use `/` to do this, you can use Path.joinpath or call Path/PurePath with multiple path segments.
- emidln 7y ago
  This is very much TIMTOWTDI. Larry Wall would be proud.
  - ben509 7y ago
    I think part of the reason Wall adopted TIMTOWTDI as a design is because he observed that it's what happens anyway, so you may as well embrace it.
  - ken 7y ago
    The first time I used Python on a team, I learned that "One Obvious Way" was a lie. In order to achieve OOW, you need really high-level features (assembly language programmers have every possible way to accomplish a task!), but also a very limited set of them (so nobody can pick the 'wrong' one). But as a general-purpose programming language, users also need power and flexibility. It's an unstable tripod where as soon as one starts getting higher, you mess up the others. I can tell they've been trying to slowly raise all three (and deprecate/remove old and lower-level pieces from the bottom), but it's a delicate balancing act, and it's easy to run into other constraints, like complexity.
okasaki 7y ago
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 7y 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 7y 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 7y 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 7y 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.
Waterluvian 7y ago
I think this is fascinating because I generally agree that Python is seeing a bunch of features it doesn't need. But then your go-to example is one of my all time favourite feature adds. I deal in path concatenation all the time. Maybe the answer is that none of us work in all the domains where Python is used, so we are all speaking with ignorance/elitism when we decide which list of features are superfluous.
agumonkey 7y ago
I won't show you my pipe library then
int_19h 7y ago
I don't think that's out of line for Python. I mean, it overloads * for string and collection repetition...

masklinn 7y ago

Note that you don't have to use `/` to do this, you can use Path.joinpath or call Path/PurePath with multiple path segments.

emidln 7y ago
This is very much TIMTOWTDI. Larry Wall would be proud.
- ben509 7y ago
  I think part of the reason Wall adopted TIMTOWTDI as a design is because he observed that it's what happens anyway, so you may as well embrace it.
- ken 7y ago
  The first time I used Python on a team, I learned that "One Obvious Way" was a lie. In order to achieve OOW, you need really high-level features (assembly language programmers have every possible way to accomplish a task!), but also a very limited set of them (so nobody can pick the 'wrong' one). But as a general-purpose programming language, users also need power and flexibility. It's an unstable tripod where as soon as one starts getting higher, you mess up the others. I can tell they've been trying to slowly raise all three (and deprecate/remove old and lower-level pieces from the bottom), but it's a delicate balancing act, and it's easy to run into other constraints, like complexity.

okasaki 7y ago

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 7y 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 7y 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 7y 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 7y 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.

Waterluvian 7y ago

I think this is fascinating because I generally agree that Python is seeing a bunch of features it doesn't need. But then your go-to example is one of my all time favourite feature adds. I deal in path concatenation all the time. Maybe the answer is that none of us work in all the domains where Python is used, so we are all speaking with ignorance/elitism when we decide which list of features are superfluous.

agumonkey 7y ago

I won't show you my pipe library then

int_19h 7y ago

I don't think that's out of line for Python. I mean, it overloads * for string and collection repetition...