[Python-ideas] __dir__ in which folder is this py file
chris.barker at noaa.gov
Thu May 17 13:30:03 EDT 2018
On Mon, May 7, 2018 at 9:17 AM, Steven D'Aprano <steve at 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
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas