On 7 May 2018 at 20:44, Steven D'Aprano <steve@pearwood.info> wrote:
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;
- about 50 or so methods and properties

Right, but that's why I think this may primarily be a docs issue, as for simple use cases, only one pathlib class matters, and that's "pathlib.Path" (which is the appropriate concrete path type for the running platform), together with its alternate constructors "Path.cwd()" and "Path.home()".

So if you spell out the OP's original example with pathlib instead of os.path, you get:

from pathlib import Path
SRC_DIR = Path(__file__).parent

And then SRC_DIR is a rich path object that will mostly let you avoid importing any of:

- os
- os.path
- stat
- glob
- fnmatch
 
As far as performance goes, I don't think it matters that we could
technically make pathlib imported lazily. Many people put all their
pathname manipulations at the beginning of their script, so lazy or not,
the pathlib module is going to be loaded *just after* startup, .

It's the fnmatch and re module imports *inside* pathlib that may be worth making lazy, as those currently account for a reasonable chunk of the import time but are only used to implement PurePath.match and _WildcardSelector. That means making them lazy may allow folks to avoid those imports if they don't use any of the wildcard matching features.
 
For many scripts, this isn't going to matter, but for those who want to
avoid the overhead of pathlib, making it lazy doesn't help. That just
delays the overhead, it doesn't remove it.

That's fine - it's not uncommon for folks looking to minimise startup overhead to have to opt in to using a lower level API for exactly that reason.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia