On Mon, May 07, 2018 at 11:42:00AM +0000, Nathaniel Smith wrote:
On Mon, May 7, 2018, 03:45 Steven D'Aprano <steve@pearwood.info> wrote:
[...]
So yes, its very distracting.
Well, yes, you do have to know the API to use it, and if you happen to have learned the os.path API but not the pathlib API then of course the os.path API will look more familiar. I'm not sure what this is supposed to prove.
From that perspective, using / to mean something kinda-sorta like string concatenation, only path separator aware, is precisely the sort of thing
Apologies for not being more clear. I'm arguing that for some people, your preferred syntax *is* more distracting and hard to comprehend than the more self-descriptive version with named functions. And its not just a matter of *learning* the API, it is a matter of using it so often that it ceases to look weird and looks natural.[1] There's a school of thought that says that operator overloading is a bad idea, that operators should never be overridden to do something aside from their common meaning (e.g. + should always mean plus, / should always mean numeric division, etc). that makes some people dislike operator overloading. http://cafe.elharo.com/programming/operator-overloading-considered-harmful/ https://blog.jooq.org/2014/02/10/why-everyone-hates-operator-overloading/ I am not going to go quite that far. I think operator overloading has its uses. I'm not going to argue that pathlib's use of / was "bad" or a mistake or harmful. I called it *weird* and that's as far as I'll go. I use lots of weird things, and I even like some of them. But if you think it isn't distracting, I think you are mistaken, and I think we ought to show caution in making it a built-in or an offical part of the module API. Your earlier comment (which I redacted): Hmm, the feedback I've heard from at least some folks teaching intro-python-for-scientists is like, "pathlib is so great for scripting that it justifies upgrading to python 3". felt to me awfully close to "pathlib! it's the future!" I know that's not what you said, or even meant, but I felt it was important to remind people that not everyone knows pathlib or finds its API clearer than the explicitly named functions of os.path. joinpath() may be longer than / but it is self-descriptive and easier to look up. help(joinpath) will tell you exactly what it does. help("/") is almost surely going to talk about numeric division, and it probably won't even mention strings or path objects at all. I say that because we've had + for string concatenation since way back in Python 1.5 or older, and yet as late as 3.6 help("+") still doesn't say a thing about string, list or tuple concatenation. As a Linux user, I'm used to paths containing slashes: $HOMEDIR/spam/eggs but putting quotes around the components looks unusual and is a hint that something usual is going on (namely a shell escape). But writing something like: HOMEDIR / "spam" / "eggs" doesn't even look like a path, just looks *wrong*. It looks like I'm escaping the wrong parts of the path: instead of escaping the spaces, I've escaped the parts with no spaces. It looks wrong as a Linux path, it looks wrong as a Windows path, and it looks wrong as division. So, yes, it is distracting. I'm not saying that everyone will feel the same way, or that I cannot or will not learn to accept / as I've learned to accept % for string interpolation despite it looking like percentage. But I'm saying it's not a slam-dunk useability win to move to pathlib.
First I have to work out what __filepath__ is, then I have to remember the differences between all the various flavours of pathlib.<whatever>Path and suffer a moment or two of existential dread as I try to work out whether or not *this* specific flavour is the one I need. This might not matter for heavy users of pathlib, but for casual users, it's a big, intimidating API with:
- an important conceptual difference between pure paths and concrete paths; - at least six classes;
The docs could perhaps be more beginner friendly. For casual users, the answer is always "you want pathlib.Path".
That might be what I want, but it isn't what I get: py> p = pathlib.Path('/') py> p PosixPath('/') I know what a PosixPath is. But the point is, even beginners have to deal with the complexity of the pathlib API the moment they print a path object in the interactive interpreter. [1] I've been using % for string interpolation for two decades now, and it still looks like a misplaced percentage sign every single time. -- Steve