On Mon, May 7, 2018 at 9:17 AM, Steven D'Aprano email@example.com wrote:
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.
then use Path.joinpath() if you want.
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.
The time for this argument was when the pathlib API was designed -- and I"m sure there was plenty of argument -- but using "/" to join paths was jsut too nifty to ignore :-)
But we are doing everyone a disservice if we essentially say:
This very useful standard library API was poorly designed, so let's stick with the old, ugly painful way...
(OK, I'm being a bit hyperbolic there ...)
TOOWTDI is a really good principle -- we never should have added pathlib if we weren't going to try to make it as useful and standard as possible.
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.
no -- but it IS clearer an easier once we get all the common functionality in there, as opposed to having to poke around in os.path, os, and shutil for what you need.
so I'll say, it even if Nathaniel didn't:
pathlib! it's the future!