On Mon, May 7, 2018 at 9:17 AM, Steven D'Aprano <steve@pearwood.info> 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!




Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception