On Mon, May 07, 2018 at 11:42:00AM +0000, Nathaniel Smith wrote: > On Mon, May 7, 2018, 03:45 Steven D'Aprano <st...@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. 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). >From that perspective, using / to mean something kinda-sorta like string concatenation, only path separator aware, is precisely the sort of thing 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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
